The field interface, with the same discipline.
A typical system has three parts: a central unit running the application, often GeminiX-based; a communication network; and several GRIO units providing remote I/O to that central unit.
NEAT / GRIO / SYSTEM ARCHITECTUREDiagram: one central unit, the network, and several GRIO units at the field elements. Draw the central unit as a neutral block labelled "central unit (GeminiX or third party)" and put PVS or RaSTA on the link. No direct communication between GRIO units.
How a GRIO system is put together.
- The central unit runs the application logic. GRIO units are logical slaves: they actuate the commanded output and report the field status back
- Each GRIO unit is two boards: the computing board, built to the GRIO Platform checklist and running the GRIO software, and an I/O board specific to the element it drives. A railway signal needs a different I/O board from a point machine
- Ethernet in both directions: requested output states out, field status read after actuation back, with non-vital inputs, statistics and logs alongside
- Diagnostics run locally, on the unit and on the element it drives. A fault is detected at the object, not inferred from its silence in the Interlocking
- No direct communication between GRIO units. Every exchange passes through the central unit
GRIO 1.0 supports PVS, GRIO 2.0 supports PVS and RaSTA. Any central unit speaking one of those protocols can command GRIO units: a GeminiX computer, an Interlocking from another supplier, or a platform the customer built. Other protocols on request.
What GRIO is made of.
A platform and its software. Everything specific to a project sits in the two plug-ins.
GRIO Platform
Requirements for the hardware and software architecture, for handling and detecting random and systematic faults, and for behaviour after detection. Plus the checklist the custom I/O must satisfy.
GRIO SW
MISRA C source managing the computing unit: safe messaging over Ethernet, cross-communication API, diagnostic routines, configuration, generic I/O drivers, and the API and cyclical call for the custom plug-in.
CUSTOM-IO HW
Translates field signals into the multifunction GPIOs, drives the outputs to the element, and provides the diagnostic GPIOs. One design per element type.
CUSTOM-IO SW
Reads the application payload, actuates the custom hardware, reads the multifunction and diagnostic GPIOs and reports them back. Written against a published API.
The platform and the base software are not modified from project to project. That is what protects the certification, and it is why a new field element is a new I/O board rather than a new product.
Status and evidence.
Third-party attribution is worth more than the claim on its own.
- Safety concept assessed by ITALCERTIFER against EN 50126, EN 50128, EN 50129 and EN 50159, up to SIL 4
- GRIO 1.0: certified, supporting PVS
- GRIO 2.0: supporting PVS and RaSTA, certification on-going
- Deployments: SRIO with Knorr-Bremse, a reference design with JMV, systems in Switzerland, India and Türkiye
- Microcontroller-class by design: small, low-power, and cheap enough to put one at every element