Automotive Electronics

How does an embedded engineering engagement with a tier supplier work?

We build the embedded and communication layers inside automotive electronics.

This is for tier-1 and tier-2 development groups. You keep the component and the OEM relationship; we take the parts that need a standing specialism:

• CAN and CAN FD, LIN, FlexRay and single-pair Automotive Ethernet integrated at node level onto your device and its silicon
• AUTOSAR Classic and Adaptive platform work, including the communication and diagnostic stacks
• purpose-built ECU nodes and in-vehicle gateways, developed from silicon bring-up and stack port upward
• UDS diagnostic services, over CAN or over DoIP where the backbone has moved to IP
• validation capacity and the CI pipeline that runs the bus, diagnostic and timing checks on every build
• the process evidence that has to be produced alongside the software instead of assembled afterwards

Most of that is component development to your own specification, delivered as your engineering partner. The engagement page sets out the modes and how they are priced.

Why has the re-platforming changed what gets outsourced?

The hard part moved, from the wiring decision to the software architecture.

Vehicles are going from a domain architecture, where each function had its ECU, to a zonal one, where compute is consolidated and functions become services reached over a network. That turns a wiring decision into a software architecture decision, and it puts a communication and middleware problem at the centre of programmes that used to be about control logic. The specialisms such a programme now needs are single-pair Ethernet bring-up, service-oriented communication and DoIP, and they arrive intermittently and in combination, which is exactly the profile that is hard to staff permanently.

Which slices of the work can you support?

Any one of the component's layers: the bus, the middleware, the diagnostic stack, the capacity to validate them.

• An unfamiliar bus. Your team has not shipped it before. CAN FD on a part that used to run classic CAN, or a first single-pair Ethernet node, taken from silicon bring-up to a device that behaves under real bus load. It also runs the other way: a FlexRay node on a platform still in production, where the specialism is getting harder to staff.
• A third-party network. A component that has to participate correctly on an architecture you do not control, including the gateway cases where it bridges two of them.
• A zonal backbone. The middleware layer an Adaptive platform runs on, and the scheduled network underneath it, taken from standards documents to something that holds under real traffic.
• A diagnostic stack moving transport. UDS that worked over CAN and now has to answer over DoIP, with the addressing, discovery and session handling that change with it.
• AUTOSAR integration capacity. Configuration and integration work on Classic or Adaptive, alongside your own platform team.
• Validation and CI capacity. Engineers into your validation team, or the pipeline that runs the regression and timing checks per build.
• Your own engineers. Brought up to speed. Training on the bus, platform or diagnostic stack, then building the first implementation alongside your team. We hold third-line support afterwards while your team runs first line.
• A whole component. A whole component built to your specification, with the OEM relationship staying yours.

What does node-level bus integration involve?

It gets a protocol running correctly on a particular device and its silicon.

That is a narrower and more exacting job than it sounds. The stack has to fit the part, the timing has to hold under real bus load, the diagnostics have to answer the way the tester expects, and the whole thing has to behave on a busy network as well as on the bench. It is the same discipline we apply on the industrial side, where our team has taken communication stacks through conformance testing on several silicon families. A CAN or LIN node in a vehicle and a fieldbus node on a machine are different networks with the same underlying question: does this device behave correctly as a participant, under load, on someone else’s network.

How does service-oriented communication reach the wire?

A middleware layer carries it, over a network that agrees to be predictable.

The middleware decides which service talks to which. Both halves are now public standards, no longer per-programme design decisions. AUTOSAR Adaptive specifies a DDS binding for the middleware half. IEEE 802.1 time-sensitive networking covers the other half at the link layer, and the OMG published DDS-TSN 1.0 in April 2023, revised as Beta2 in May 2024, setting out how one maps onto the other.

The engineering is in that mapping. A topic carries quality-of-service settings (reliability, durability, deadline, liveliness) while the backbone carries a repeating schedule of windows. Deciding which topics get a protected window, which share what is left, and what the system does when a subscriber misses its deadline is a design exercise rather than a configuration file. Get it wrong and the result behaves on the bench, then degrades under load in a way that looks like an application fault when it is a network one. For a tier supplier the practical question is usually narrower than the architecture debate. The platform is already chosen, and integrating DDS on AUTOSAR Adaptive has to work on a particular device, against a backbone you do not control, alongside traffic from teams you do not manage. That is the node-level question from the section above, asked of a newer layer.

Where do diagnostics sit now?

UDS is unchanged in what it does, but increasingly it no longer travels over CAN.

As the vehicle backbone moves to IP, the same diagnostic services are carried over DoIP, and the transport change is more consequential than it first appears. Addressing, discovery, session handling and security all behave differently. Work that assumes CAN transport tends to need rethinking, not porting.

How do you produce the process evidence an OEM audit expects?

Alongside the software, because on a tier-1 platform the evidence gates the work.

Three assessments read the same trail:

• Automotive SPICE, which suppliers are assessed against.
• ISO 26262, which brings functional safety with its own artefact expectations.
• ISO/SAE 21434, which has added cybersecurity engineering to the same list.

None of that is unusual or unreasonable. It is how the sector manages risk across a supply chain it cannot inspect directly. In practice that means the traceability from requirement to test result is built as the work proceeds, on your process and in your toolchain, so what reaches an assessment is your evidence trail with our work inside it.

Is this the same team that does your industrial work?

Yes, and that is deliberate.

Vehicle electronics and industrial automation have converged on the same problems: deterministic Ethernet, time synchronisation, service-oriented communication, functional safety and cybersecurity obligations arriving together. The bus names differ. The engineering underneath is portable, which is why our embedded systems and real-time Ethernet work spans both.