Contemporary elevator controllers bridge the gap between the safety-critical world and modern communications technology — placing high demands on the underlying hardware architecture. The solution lies in a platform already proven in automotive environments.
Connectivity Comes to the Building
The accelerating digitalization of enterprises and public infrastructure relies on an ever-growing number of networked devices. Information Technology (IT) and Operational Technology (OT) devices alike must provide sufficient digital interfaces to exchange data with one another and via the cloud. This applies across industries including industrial automation, automotive, transportation, logistics, and medical technology — and connectivity is now making strong inroads in building technology as well.
In elevator control systems in particular, digital elements such as modern Human Machine Interfaces (HMIs) for user interaction are playing an increasingly prominent role. They deliver comfort features such as voice input and enable predictive maintenance of elevators, increasingly powered by artificial intelligence (AI).
As a result, OT devices like elevator controllers are evolving away from conventional technology and toward safety-critical, networked infrastructure. With more digital components comes greater demand on the technology deployed — especially the embedded modules that form the heart of every controller.
The Elevator as a “Vertical Software-Defined Vehicle”
Driven by growing connectivity, elevators face a challenge very similar to the one the automotive industry confronted about five years ago: many individual control units each fulfill their specific function, but prevent a holistic, scalable system architecture. The challenges range from integrating functional additions such as touch HMIs and managing differing innovation cycles across components, to increasing networking demands for smart-building features and fleet management. Compounding the problem, multiple suppliers independently evolve components such as drives or HMIs, leading to a fragmented landscape of heterogeneous devices. Developers must consolidate this sprawl and integrate it into a unified control architecture.
Passenger elevators today, however, operate at the intersection of two fundamentally different worlds: the dynamic IT world and the strictly regulated OT world. While IT typically operates fast, data-driven, and connected — with frequent software updates — OT operates deterministically and is driven by safety standards and norms, governing systems such as emergency braking and safety catches. This creates a collision between short innovation cycles demanding high compute performance and hard real-time requirements with deterministic behavior. Attempting to merge both worlds on a monolithic architecture almost invariably leads to serious problems — problems that can have severe consequences in safety-critical situations. It is therefore strongly advisable to separate the IT and OT domains at the hardware level.
Rather than relying on many individual function-specific control units, a unified architecture instead deploys powerful zone and domain controllers to aggregate functions within clearly defined system areas. In a classical elevator controller, for example, separate controllers can be established for drive and braking, HMI and display, and communications and diagnostics. Zone and domain controllers each consolidate individual functions into logical building blocks while maintaining strict separation between the IT and OT worlds.
The Architecture Gap: The Mixed-Criticality Problem
In monolithic control structures, safety-critical OT functions collide with IT-adjacent functions such as HMI and cloud connectivity. For example, a routine software update can inadvertently disable essential safety functions. Moreover, monolithic architectures are difficult to scale to varying market requirements, and maintenance, fault diagnosis, and update deployment all demand significant effort. For these reasons, monolithic structures are no longer adequate for modern passenger elevator controllers.
Classical Programmable Logic Controllers (PLCs), microcontrollers (MCUs), or pure industrial PCs are constrained in their AI compute capacity, often lack support for modern software stacks, and cannot scale sufficiently. Industrial PCs, moreover, lack adequate real-time capability and certification, and present a large attack surface for cyber threats.
Developers should therefore adopt a heterogeneous computing approach, integrating two specialized compute domains that together support both the IT and OT worlds. A so-called Safety Domain handles all safety-critical functions — emergency braking, door monitoring, speed control, and fault detection — while an Application Domain manages visualization, cloud and building connectivity, data analytics, and diagnostic functions. The critical principle is to physically separate the two domains while allowing them to communicate with one another.
Figure 2. The integrated Arm Mali-G310 2D/3D GPU, with OpenGL and Vulkan support, handles the HMI’s graphics and ensures that the display and control elements are rendered correctly. In addition, the integrated eIQ Neutron N3-1024S NPU delivers up to 2 TOPS.
This principle is not new — it has been in use for years in industries such as automotive and industrial automation. In the Safety Domain, for instance, automotive-grade MCUs with lockstep cores can be employed. For the Application Domain, developers can leverage SoCs with multicore architectures and AI accelerators.
NXP Gold Partner MicroSys Electronics applies this architectural principle in its System-on-Modules (SoMs), providing a hardware foundation for modern passenger elevator controllers. Customers receive not only the module itself: MicroSys also supports the development of custom carrier boards where required, accelerating integration into the specific control environment. The miriac MPX-i.MX95 SoM, for example, serves as the Application Domain, while the miriac MPX-S32G399A functions as the Safety Domain.
Application Domain: The Interface to the Outside World
Powered by NXP’s integrated i.MX95 processor, the miriac MPX-i.MX95 can process AI workloads at the edge, act as a security gateway, and handle all HMI functions of the elevator (Figure 2). The i.MX95 CPU operates with six Cortex-A55 cores at up to 2 GHz, along with a real-time-capable Arm Cortex-M7 core at 800 MHz and a Cortex-M33 core at up to 333 MHz. Application and communication functions run on the Cortex-A55 cores, while time-critical tasks execute deterministically on the Cortex-M7/M33 cores — a typical partitioning strategy for modern embedded systems.
The integrated Arm Mali-G310 2D/3D GPU with OpenGL and Vulkan support handles HMI graphics, ensuring that display and control elements are rendered correctly. In addition, the integrated eIQ Neutron N3-1024S NPU delivers up to 2 TOPS (Tera Operations per Second), significantly boosting control efficiency. Where AI algorithms previously ran alongside graphics workloads on the GPU, the NPU in the i.MX95 offloads the graphics core and ensures smooth rendering of display elements while simultaneously executing AI tasks at full compute throughput (Figure 2). The NPU leverages connected cameras not only for surveillance but also for analytics such as counting occupants or detecting falls and vandalism.
To ensure smooth data throughput, the module provides 16 GB LPDDR5 memory at up to 6.4 GT/s (Giga-transfers per second), along with an NFC-configurable EEPROM for storing data such as serial numbers or user configuration with up to 16 kB. Connectivity is provided via industrial-grade interfaces including 1× 10 Gigabit Ethernet, USB 2.0/3.0, PCIe, I3C, SPI, UART, and MIPI-CSI. The module measures 82 mm × 35 mm and is rated for the industrial temperature range of −40 to +85 °C. The Arm TrustZone architecture enables the module to function as a security gateway, serving as a firewall toward the cloud and protecting the underlying control system from unauthorized access.
Figure 3. The miriac MPX-S32G399A serves as the safety domain in modern passenger elevator control systems.
Thanks to its extensive video, audio, and camera interfaces, the miriac MPX-i.MX95 is well-suited to managing user communication via HMI — displaying the selected and current floor, as well as additional information such as the time, date, or emergency call functions. Critically, it carries no safety-relevant authority: if the display crashes, the elevator continues to travel to its selected destination and safely delivers its passengers.
Safety Domain: The Bedrock of Reliable Operation
Alongside the miriac MPX-i.MX95 as Application Domain, the miriac MPX-S32G399A serves as the Safety Domain (Figure 3) in elevator controllers. It is responsible for passenger safety and is fully isolated from the Application Domain to prevent mutual interference. The miriac MPX-S32G399A is built around NXP’s S32G399A CPU, featuring eight Arm Cortex-A53 cores together with four Arm Cortex-M7 dual-core lockstep pairs, backed by 4 GB soldered LPDDR4 RAM, 64 MB QSPI Flash, and up to 32 GB eMMC storage.
The CPU employs dedicated Safety Islands rather than pure software-based solutions. In lockstep mode, two parallel cores execute the same task simultaneously; if their results differ by even a single bit, the system immediately detects the error and initiates a safe state (fail-safe) (Figure 4). This allows random hardware faults — such as bit errors — to be detected early; in the event of a fault, the controller can trigger a defined safety response, such as a safe stop or transition to a defined safe state.
The module also provides high-bandwidth communication interfaces including up to 3× 2.5 Gigabit Ethernet or up to 4× 1 Gigabit Ethernet, PCIe, 4 SerDes lanes, and ULPI USB. Extensive I/Os — including 4× FlexSPI, 2× UART, 18× CAN FD, 2× FlexRay, 4× LIN, 4× I2C, and GPIOs — support communication with connected peripherals. The integrated Hardware Security Engine (HSE) provides secure boot and accelerates the security services required by the elevator controller. The module is likewise rated for the extended temperature range of −40 to +85 °C, enabling operation in harsh environments.
Figure 4. The CPU uses so-called safety islands instead of pure software to isolate tasks from one another. Lockstep operation ensures that two processing cores compute the same task for error detection.
The high-speed I/Os guarantee real-time communication via CAN-FD and Time-Sensitive Networking (TSN). TSN ensures deterministic data transmission across the network: packets carrying emergency-stop commands always take priority in network traffic over diagnostic or video data. This enables deterministic, prioritized communication — time-critical safety telegrams can be transmitted with guaranteed transmission windows and defined priority relative to diagnostic or video data. This is essential when milliseconds determine passenger safety. A further advantage is the extensive certification of the S32G processor: changes to the application do not require new safety certifications of the S32G (Freedom from Interference), making future adaptations straightforward.
The Critical Interface: How IT and OT Communicate Safely
In the interplay between the two domains, it is important to note that the Application Domain — the miriac MPX-i.MX95 — processes user interactions and system data, but makes no safety-relevant decisions. Rather than issuing commands directly, it transmits only a request — for example, that a passenger wishes to open the door. The Safety Domain — the miriac MPX-S32G399A — evaluates this request against all safety-relevant states and alone decides whether to approve or deny the action.
To simplify updates and future extensions, all required software updates are received, verified, and prepared via the Application Domain on the i.MX95. Only after the i.MX95 has verified the digital signature of the update package and confirmed its integrity is it forwarded to the Safety Domain on the S32G. Asymmetric cryptographic and signature schemes are employed throughout, ensuring that only authorized, signed software packages from the manufacturer are accepted. Secure OTA (Over-the-Air) updates thus enable regular updates without compromising the certified safety functions through manipulation.
Application and Safety Domain Working in Concert
A practical example illustrates how the Application and Safety Domains can be properly separated in a passenger elevator. An elevator that previously operated “blind” had no awareness of how many people were waiting, or whether a passenger inside needed assistance. With the MicroSys architecture integrated into the elevator controller, the picture changes entirely.
Consider the scenario of an “impatient morning commuter rush” in an office building at 8:30 a.m. The Application Domain of the miriac MPX-i.MX95 captures waiting passengers in the cab and the elevator lobby via camera, and analyzes the data locally on the NPU: “Five waiting individuals, one in a wheelchair.” The CPU makes a strategic decision: “Hold the door open three seconds longer for the wheelchair user and prioritize floor five, where the open-plan office is.” It also transmits a request to the controller to hold the door open longer, giving all passengers sufficient time to board. At the same moment, an impatient occupant attempts to force the door closed or blocks the light barrier.
In the Safety Domain of the miriac MPX-S32G399A, the following now occurs: the S32G processor receives the i.MX95’s request to hold the door open longer. Simultaneously, it monitors the door lock sensors and motor temperature in the millisecond range in real time. It intervenes the moment it detects that the door motor current is rising due to the obstruction. It therefore overrides the AI’s “comfort request” and instead immediately triggers the safe reversal sequence — causing the door to reopen to prevent crushing injuries — and returns a status message: “Command denied, safety intervention active.”
This example demonstrates how Application and Safety Domains collaborate effectively in modern elevator controllers. The physically separated hardware architecture from MicroSys accommodates both passenger comfort and safety simultaneously.
Conclusion
When developers want to incorporate connectivity, cloud integration, or AI capabilities into elevator controllers, they must strictly isolate safety-critical functions from comfort and display functions in order to maintain compliance with standards and certifications at all times. MicroSys System-on-Modules provide the hardware foundation for this separation as a ready-made, validated architecture, consolidating both the Application and Safety Domains on a single platform. Elevator manufacturers use this foundation to implement their software solutions efficiently: the Application Domain handles HMI, data analytics, AI, and communications, while the Safety Domain deterministically supervises all critical control functions.
By deploying these System-on-Modules, system integrators and manufacturers are empowered to simplify the complex integration of hardware, software, and safety mechanisms — resulting in a system that enables both innovation and flexibility while simultaneously reducing development time and certification risk.
