Mobility

How does a mobility platform control network engineering engagement work?

We engineer the control network inside a mobility platform: redundancy, signalling paths and acquisition.

What we take is the network, the redundancy scheme and the acquisition inside your product. For a rolling-stock builder, a shipyard or an airframe integrator that means:

• The protocol and network layer, from stack port and board bring-up through to a running redundant control network.
• The supervisory and information layer, where operator stations and monitoring systems read the platform without joining the control loop.
• The acquisition layer, where distributed IO is read, timestamped and carried to where the record is stored.
• Integration and test with your engineers, onshore and remote, against real equipment.
• Training and third-line support afterwards, behind your own first line.

You keep the platform, its qualification, its operator relationship and its domain expertise. We do not commission on the vessel, the train or the aircraft. Where a design has to be integrated and tested, our team works with your engineers, onshore during integration and test and remotely for the rest. The engagement page sets out the modes and how they are priced.

Why is this layer bought in rather than built?

It is a standing specialism that a platform builder needs intermittently.

A shipyard, a rolling-stock builder or an airframe integrator employs deep expertise in propulsion, structures, braking and certification. Communication stacks, redundancy schemes and real-time network engineering are needed intensely during a programme and then not again for years, which makes them expensive to keep in-house and easy to let decay between programmes. The second pressure is that the platforms outlive their electronics by a wide margin. A control system specified today will see its processors, its network silicon and possibly its protocol go end of life while the vehicle is still in service. Someone has to carry it forward, and the original design team is usually long since assigned elsewhere.

Which slices of the work can you support?

Any one of the layers inside the platform: the control network, the signalling path, the machinery interface, the acquisition.

• Redundant control networks. Redundancy engineered at three levels: redundant masters on the control network, redundant servers for the supervisory layer, and dual-redundant physical links between them. Each level fails over on its own, so a cut cable, a failed interface or a lost controller degrades the system by one element instead of dropping a section of the platform.
• Signalling and interlock paths. Deterministic data paths where a missed cycle is a safety event rather than a quality one, built on real-time Ethernet with a dual-master arrangement so control has a standby ready to take the cycle.
• Machinery and engine-room integration. Packaged equipment communicating over the bus its supplier ships, integrated at the controller so each segment keeps its native protocol and cycle while the controller publishes one normalised view upward.
• Acquisition and time sync. Distributed IO read and timestamped against a common clock, so records from units in different parts of the platform can be compared afterwards.
• Operators and ground systems. OPC UA and DDS layers carrying state outward, engineered so a subscriber can be added without disturbing the control cycle beneath it.

How is redundancy engineered so no single fault stops control?

Redundancy is engineered at three levels: the master, the link and the node.

Each level fails independently of the others. A standby master takes over the cycle when the active one stops. Traffic reroutes onto the surviving path when a link breaks. A node with two interfaces stays on the bus with one port down. None of these depends on the others, which is what stops a single fault cascading. Time synchronisation is what makes a takeover continuous instead of a restart. PTP keeps the standby aligned with the active node, so it assumes the cycle already in phase with the rest of the network. A publish and subscribe backbone does the same job by ranking its publishers: subscribers move to the standby writer on the next sample, without waiting for a supervisory system to notice the failure. Scaling changes how the nodes find each other. A small system can let every node discover every other node directly. Across several segments that full-mesh discovery becomes hard to maintain, so discovery moves to a central server, which can itself be made redundant. Joining nodes learn the topology from a known point, and commissioning becomes a controlled step instead of a broadcast storm.

What does real-time signalling demand that ordinary control does not?

A guarantee that holds under fault, not only under load.

Signalling data paths are engineered with two masters arranged so that control is never waiting for a single node to be replaced, and on real-time Ethernet the cycle is short enough that a takeover completes inside the tolerance the application allows. Our team has delivered signalling-side real-time control of this shape on an Ethernet POWERLINK network with a redundant dual-master arrangement. The protocol matters less than the property being bought, which is that the network has a designed behaviour when a master disappears. The newer question in this sector is information exchange rather than control. Railway operators are standardising the interfaces between signalling equipment and the systems that supervise it, and OPC UA is being adopted as the transport for it. Our own recent work here is a proof of railway real-time information exchange over OPC UA. In open source, Systerel also publishes that its S2OPC stack sits in signalling supervision gateways and on EULYNX-compliant platforms, which is useful corroboration that the direction is real and not a single operator’s preference.

How do installed machinery packages join one control system?

At the controller, without demanding a common bus.

A thruster drive arrives on CANopen, a packaged auxiliary on Modbus TCP, a motion axis on EtherCAT. Each segment keeps its native protocol and its own cycle, and the controller publishes a normalised view of all of them onto the backbone, so operator and monitoring layers see one consistent system regardless of what each package speaks underneath. This is also where wiring gets simplified. Equipment with every sensor and actuator hardwired back to a central cabinet is a commissioning burden and a maintenance burden for the whole service life, and moving to distributed IO on a network removes both. For cases where the interface mix is known up front, one purpose-built device carrying the protocols and interfaces the platform actually needs can replace several off-the-shelf modules, taking out cost and shrinking the obsolescence surface at the same time.

What is involved in onboard acquisition and time synchronisation?

Acquisition reads distributed IO reliably; time synchronisation makes the records comparable.

• Acquisition is reading distributed IO reliably from units spread across a platform, on the respective interfaces each unit provides, at a rate that does not lose events.
• Time synchronisation is making the resulting records comparable, which means every unit timestamping against one shared clock.

The second is what decides whether the data is useful afterwards. Two units recording the same event against unsynchronised clocks produce a record that cannot be ordered, and no post-processing recovers that ordering. It is why the telemetry standards governing airborne acquisition carry time representation inside the packet structure itself, not left to the application.

Our team has built the IO data and time-synchronisation halves of an onboard acquisition system communicating with a ground station over a customer-defined protocol. The protocol was theirs; the acquisition and the synchronisation underneath it were the parts that needed the specialism.

Which platforms do you work on?

Rail, marine, engine-room and airborne systems; road-vehicle electronics is a different engagement.

The common property is a platform that moves, cannot be serviced while operating, and carries equipment from several suppliers that has to behave as one system. Road vehicles have their own pages and their own buyer. If you are building ECUs, in-vehicle networks or domain controllers, automotive electronics is the one you want. If you are building plant that manufactures vehicles, that is automotive.