User manual

Safety and responsibility

Download PDF

Data Orchester reads, computes, shows, logs and writes the values of your plant. It is not a safety system. This page says where its responsibility ends and yours begins, and how to keep the two apart when you design an installation.

Caution

Data Orchester is not a safety instrumented system in the sense of IEC 61508 and IEC 61511. It must never be the only layer of protection against a hazard to people, the environment or equipment. Safety functions, such as emergency stops, interlocks, trips and pressure or level protections, belong to certified safety systems and to the hard-wired protection of the plant.

What Data Orchester is for

Monitoring, supervisory control, data acquisition, logging, dashboards and integration between systems. Its engine, its modules and its links to devices run on general-purpose computers and networks; none of them is designed, certified or tested to the integrity a safety function needs.

Writes to the plant are yours

Data Orchester writes to devices when your configuration tells it to: inputs and Action buttons on dashboards, formulas and modules that write variables, and the control modules — PID, PWM and the Kalman filter — that drive outputs on their own clock. Each of those writes is part of the installation you design. You, or whoever commissions the installation, are responsible for:

  • deciding which values Data Orchester may write, and to which devices;
  • the limits, ramps and fallbacks each written value needs;
  • testing every write path before it reaches live equipment, and again after each change;
  • commissioning the installation, and keeping its documentation current.

Good practice

  • Keep interlocks in the device. A PLC or a relay holds the interlocks and limits a process needs, so a wrong value written by Data Orchester, or by anyone, cannot take the plant outside its safe envelope.
  • Write only what must be written. Give the modules that write to devices only the addresses they need, and keep connections that only read read-only. Grant the roles that operate controls only to the people who should operate them.
  • Test off-line first. Try a new program, control loop or dashboard against a simulator, a test device or an instance that writes to nothing, before it writes to the plant.
  • Plan for silence. Decide what each device does when Data Orchester stops writing — after a restart, a network fault or an engine stopped for want of a licence — and set that behaviour in the device.
  • Treat AI proposals as drafts. The AI assistant only proposes changes; it never saves and never writes to the plant. Its proposals can be wrong: review every change as you would one written by a colleague, and test it before it goes live.

Next steps