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.

The post Moderne Architekturen für Aufzugsteuerungen appeared first on MicroSys.

Nicht nur PKW, Busse oder Lieferwagen werden künftig autonom agieren. Für die Automatisierung mobiler Arbeitsmaschinen schuf MicroSys auf Basis aufgabenoptimierter System-on-Module aus eigener Entwicklung ein modulares einbaufertiges Gesamtsystem. Dank nur 60 W Leistungsaufnahme ohne aktive Kühlung, eignet sich die Autonomous Control Unit (ACU) hervorragend für den jahrelangen Einsatz unter rauen Arbeitsbedingungen.

Beim Thema „autonomes Fahren“ sind meist Personenkraftwagen (PKW) gemeint, seltener Busse oder Lieferwagen, die sich fahrerlos im öffentlichen Straßenraum bewegen. Diese sind jedoch keineswegs die einzige Anwendung für diese komplexen Navigationsverfahren. Auch selbstfahrende Arbeitsmaschinen wie z. B. landwirtschaftliche Maschinen, Baumaschinen und Flurfördergeräte haben ein erhebliches Automatisierungspotenzial.

Ziel: hochautomatisierte Arbeitsmaschinen

Die Aufgabenstellung unterscheidet sich erheblich von der an autonome Fahrzeuge des Straßenverkehrs. Landwirtschafts- und Baumaschinen bewegen sich bei ihrer gewöhnlichen Nutzung meist nicht im öffentlichen Straßenraum, sondern in abgegrenzten Baustellenbereichen, in die Unbeteiligte keinen Zugang haben. Dabei kann nicht vom Navigieren auf weitgehend ebenen Flächen ausgegangen werden, sondern von Fahrten im Gelände. Dieses – und damit die Basis für die Überprüfung des Fahrkurses – verändert sich durch den Baufortschritt ständig und muss laufend neu erkannt werden. Zudem sollen sich die autonomen Handlungen nicht auf die Fahrbewegungen beschränken, sondern ebenfalls die Lastaufnahme und -übergabe umfassen.

Bis auf unseren Äckern und Baustellen autonom navigierende und agierende Arbeitsmaschinen Normalität sein werden, sind noch einige grundlegende Voraussetzungen zu schaffen. Das deutsche Bundesministerium für Wirtschaft und Klimaschutz (BMWK) unterstützt die Transformation der Branche mit dem Förderprogramm KoPa 35c, welches bis 2024 unter anderem Fahrzeugherstellern und der Zulieferindustrie in Deutschland zugutekommt.

Im Verbundprojekt POV.OS – Professional Vehicle Operating System soll dazu eine innovative Automatisierungsplattform als offene Architektur aus Hardware und Software für den Einsatz und die Funktionalisierung mobiler Arbeitsmaschinen entwickelt werden. Dabei geht es um die Schaffung einer anwendungsübergreifenden Plattform mit modularen Systemkomponenten, die als Grundlage für eine Spezifizierung und Umsetzung anwendungsbezogener Automatisierungs-, Assistenz- und autonomer Fahrfunktionen genutzt werden kann.

Wirtschaftlich durch Modularität

Mobile Arbeitsmaschinen werden in deutlich geringeren Stückzahlen produziert als gängige Automobile. Eine vollständige Neuentwicklung der zentralen Steuerungselektronik wäre daher für ihre Hersteller wirtschaftlich nur schwer darstellbar. Deshalb bevorzugen diese kommerziell verfügbare sogenannte COTS-Plattformen (für commercial off-the-shelf). Diese ermöglichen den Entwickelnden, individuelle Lösungen zu schaffen, ohne sich bei der Geräteentwicklung mit den einzelnen Komponenten auseinandersetzen zu müssen.

Als probates Mittel dazu entwickelt die MicroSys Electronics GmbH (MicroSys) als Gold Partner des Prozessorherstellers NXP System-on-Module (SoM). Diese in kleinen Formfaktoren hergestellten Baugruppen enthalten neben dem Mikroprozessor und dem Speicher sowie zahlreichen Kommunikationsschnittstellen alle Komponenten, die für die Applikationsentwicklung und Zertifizierung benötigt wird. So ermöglichen SoMs als zentrale Recheneinheiten mit standardisierten Schnittstellen Herstellern professioneller Arbeitsmaschinen die rasche Entwicklung ihrer Produkte. Die anwendungsspezifische Spezialisierung erhalten SoMs hardwareseitig durch zielgerichtete Trägerplatinen, sogenannte Carrierboards. Diese dienen unter anderem der Stromversorgung der Module und der Übersetzung der Ein- und Ausgangssignale in branchenspezifische Formate.

Ein starkes Herz

Nicht nur für mobile Arbeitsmaschinen, sondern für ein breites Spektrum an Anwendungen mit ähnlichen Performance- und Sicherheitsansprüchen entwickelte MicroSys das SoM miriac® MPX-LX2160A. Basierend auf dem LX2160A als derzeit schnellstem Embedded Multi-Core-Prozessor aus dem Hause NXP mit 16 Arm® Cortex®-A72 Prozessorkernen, bietet das Modul im Standard 32 GB aufgelötetes DDR4 RAM, das auf bis zu 128 GB erweiterbar ist. Die prozessorintegrierten Ethernet-Controller ermöglichen eine höchst performante High-End Kommunikation mit bis zu 100 Gbit/s Ethernet und integriertem 122-Gbit/s Layer 2 Ethernet Switching. Damit lassen sich alle Vernetzungsaufgaben im Fahrzeug integrieren, bis hin zu GigEVision Kamerasystemen.

Vier PCIe 3.0 Schnittstellen ermöglichen die Ausstattung des SoM mit dem dafür erforderlichen, großen SSD-Massenspeicher. Die integrierte Security Engine des NXP-Prozessors LX2160A ermöglicht bis zu der maximalen Übertragungsbandbreite eine lückenlose Daten-Verschlüsselung. Sie stellt mittels Secure Boot sicher, dass – etwa bei Software-Updates – nur Software aus zertifizierter Quelle geladen wird. Mit mindestens 15 Jahren Verfügbarkeit bietet das für einen Temperaturbereich von mindestens -40° C bis +85° C spezifizierte miriac® MPX-LX2160A Herstellern mobiler Arbeitsmaschinen eine hohe Versorgungssicherheit der Kernkomponente.

Aufgabenoptimiertes Carrierboard

Das zentrale Prozessormodul allein ist nicht alles. Viele Hersteller mobiler Arbeitsmaschinen verfügen nicht über die erforderlichen Kompetenzen oder Kapazitäten zum Aufbau eines von diesem angetriebenen Gesamtsystems. Für die Entwicklung einer aufgaben-, aber nicht kundenspezifischen Steuerungsplattform für mobile Arbeitsmaschinen nutzte MicroSys einerseits Erkenntnisse, die das Unternehmen in POV.OS (Professional Operating Vehicles Operating System POVOS) gewinnt. Ebenso lässt der bayerische Hersteller seine jahrelange Branchenerfahrung und weitere Kundenanforderungen, beispielsweise aus dem Baumaschinen-Segment, mit einfließen.

Das im POV.OS Kontext angedachte COTS-Carrierboard von MicroSys bietet 3 M.2 Slots und kann mit folgenden Modulen bestückt werden: ein miriac® MPX-LX2160A, ein FPGA-Beschleunigermodul, bis zu drei SSD-Speichermodule oder ein bis zwei Hailo-8™ KI-Prozessormodule. Für den Fall, dass im Projektkontext eine separate Safety Insel benötigt wird, bietet MicroSys basierend auf dem miriac® MPX-S32G274A oder miriac® MPX-S32G399A eine Lösung zur Erweiterung an. Das schafft zusätzliche Rechenleistung für komplexe Aufgaben und eine unabhängige Kontrollinstanz.

Einbaufertiges Gesamtsystem

Zu einem einbaufertigen ruggedized Gesamtsystem wird die Elektronik durch das völlig neu entwickelte Gehäuse. Staub- und wasserfest nach Schutzart IP 68, führt es in der Basisversion zehn GB Ethernet-Schnittstellen über M12-Stecker sowie serielle Datenbusse über einen robusten Fischer-Steckverbinder aus. Über einen betriebsbewährten Deutsch-Steckverbinder erfolgt die Stromversorgung und die Ausführung von drei CANbus-Strängen. Eine wesentliche Aufgabe des Gehäuses ist neben dem Schutz der verbauten Elektronik die Wärmeableitung. Die dabei entstehende Abwärme wird in erster Linie über die Grundplatte an das Fahrzeugchassis abgegeben, an die das Gerät geschraubt ist. Ein kleinerer Teil der Abwärme gelangt über Kühlrippen an der Gehäuseoberseite direkt in die Umgebungsluft.

MicroSys ist es gelungen, die Leistungsaufnahme der voll bestückten Einheit trotz der extrem hohen Verarbeitungsleistung und der Vielfalt an Schnittstellen auf 60 W zu begrenzen. So kommt die Einheit nicht nur ohne bewegliche Teile, sondern auch ohne aktive Kühlung aus. „Die bisherigen Tests bestätigen die hinreichende Kühlwirkung bis zu einer Umgebungstemperatur von mindestens 55°C“, bestätigt Jörg Stollfuß, Applikationsingenieur bei der MicroSys Electronics GmbH. „Mit der neuen Autonomous Control Unit auf Basis des SoM-Moduls miriac® MPX-LX2160A können wir Herstellern mobiler Arbeitsmaschinen ein einbaufertiges Gesamtsystem für die Automatisierung ihrer Produkte anbieten.“ „Mit der neuen Autonomous Control Unit auf Basis des SoM-Moduls miriac® MPX-LX2160A können wir Herstellern mobiler Arbeitsmaschinen ein einbaufertiges Gesamtsystem für die Automatisierung ihrer Produkte anbieten.“

The post Basis für fahrerloses Baggern appeared first on MicroSys.