What GeminiX is, before any product.
An embedded virtual platform for safety-critical systems at high SIL, providing base software and hardware design components independent of the final platform hardware.
Why a virtual platform.
Certified operating systems solve part of the problem: they are largely independent of the underlying hardware, and porting costs are confined to a new board support package. They do not solve diagnostic coverage.
Systems at high integrity levels need to detect not only the single fault, which mutual comparison catches, but the accumulation of latent errors. That requires continuously verifying sub-systems that are not easily verifiable, and it is where an FPGA earns its place: measures written in (V)HDL are verifiable, reusable and largely independent of the hardware around them.
NEAT / PLATFORM / BLOCK DIAGRAMThe safety architecture.
Each safety-related function is performed by two independent nodes joined by a galvanically insulated cross-link.
A dual diverse electronic structure based on composite fail-safety with fail-safe comparison, which EN 50129 Table E.4 marks as Highly Recommended for safety integrity levels up to 4. Under IEC 61508-2 it is a type B subsystem with HFT = 1 and a safe failure fraction at or above 99%, which is what carries it to SIL 4. In everyday conversation people call this 2oo2; the normative wording is the one above.
The assumption the architecture rests on is worth stating publicly, because a serious evaluator will ask: no single random fault is dangerous, because a hazardous fault in one channel is detected and negated before a second fault occurs in the other. Only multiple faults, including common cause failures, can be dangerous.
What each node contains
- Processing unit: CPUs, internal memories, non-vital I/O and optionally other RAM
- GeminiX-Cores, with an independent internal clock
- Dedicated volatile memory
- Dedicated mass memory, protected by a safety code
A diagnosable bus interconnects them, with the processing unit as master and the other devices memory-mapped into its address space. The platform can be redounded for higher reliability.
GeminiX-Cores: the measures, named.
Publishing the list is unusual. It is also the fastest way for an assessor to decide whether the platform is serious.
- A system controlling failures in the dedicated RAM during operation
- A passive memory protection unit, for spatial task segregation
- A time-window watchdog, for temporal task segregation
- A cross-communication channel with synchronisation capability
- A DES signature calculator
- A cross-power monitor
- A bus monitor
And the generic I/O.
- MAC core for Ethernet with IP capability
- UART core for RS232, RS485 or RS422
- LED controller
- GPIO interface
- SPI controller
- I2C controller
A low-end example on a widely used ARM SoC targeting medium performance, low power, low size and low cost; a high-end example on a high-performance processor with a high-end FPGA. Both are GeminiX-Platform instances.
What it is used for.
The platform is domain-independent. These are the applications it has actually served.
Electronic Interlocking
Station and wayside signalling, with GRIO at the field interface.
ERTMS and RBC
The RBC Generic Product runs on a redundant GeminiX configuration.
KAVACH
Indian train collision avoidance, in production on 1100 trains.
National ATP
On-board and wayside vital computing to national specifications.
Object controllers
Through GRIO, with PVS or RaSTA as the safe protocol.
Space
GeminiX-OS-Space, the space member of the same OS family.