Skip to main content

How YTCC works

The YTCC server is a set of separate programs that work together. A process manager starts them, watches them and restarts any of them that stops.

What runs on the server​

Some services run all the time: the web interface, the project server that stores screens, the live data server that sends values to browsers and a message bus that carries values between services.

When a project starts, YTCC adds the services that project needs:

  • one process for each active driver, read from the project's configuration
  • the alarm service
  • the history writers that archive values
  • one process for each enabled server script
  • the services behind the system signals and, for electrical projects, the network topology

You can see these processes on the Processes tab of the home page.

When something fails​

Each driver runs in its own process. If one driver stops because of an error, the other drivers and services keep running, and the process manager starts the stopped driver again. It waits 1 second before the first restart, then 2, 5, 10 and 30 seconds, and after that tries every 30 seconds without a limit. A driver that runs without problems for 60 seconds starts the count again from 1 second.

A process that stops because its version does not match the project data is not restarted. It is marked as failed.

How screens get their values​

A screen asks the server only for the signals it shows, and the server sends each browser only the values it asked for. A screen with 50 signals receives those 50 values, however many signals the project has.

Pages you have already opened stay ready in the background, so switching back to them shows live values at once. Hidden pages together keep up to 20,000 signals live. Above that, the page you used least recently stops receiving values; when you return to it, it first shows its last values marked as stale and then updates. A browser tab that you send to the background stops receiving values after 2 seconds.

If the browser loses its connection to the server, it keeps trying to reconnect, with waits of up to about 30 seconds. While it is disconnected, command buttons are unavailable, and the runtime screen shows a banner at the top. When the connection is back, the screen asks again for its signals.

Where data is kept​

  • Configuration (drivers, devices, signals, alarms): in the project's PostgreSQL database.
  • History and alarm records: in the project's own history database, also in PostgreSQL. Alarms that were active when the server stopped are restored from there when it starts.
  • Screens and users: in files on the server. See Project model.