SOME/IP and Automotive Ethernet: Service-Oriented Architecture for the Software-Defined Vehicle (2026)

For three decades a vehicle network was a bus of signals. An engine controller shouted “coolant temperature is 91 degrees” every 10 milliseconds, whoever cared listened, and the sender never knew or cared who that was. That model is superb for deterministic control loops and miserable for a car whose behaviour is now defined by software that ships after the vehicle is sold. A feature such as a hands-free parking assist needs to call functions on other computers, discover them at runtime, and survive being updated independently of them.

SOME/IP, Scalable service-Oriented MiddlewarE over IP, is the protocol the AUTOSAR ecosystem standardised for exactly that job. It runs over automotive Ethernet and gives a vehicle remote procedure calls, publish/subscribe events, field access and dynamic service discovery with a very small header. Understanding it means understanding the physical layer beneath, the time-sensitive networking features that make it predictable, and the zonal architecture it serves.

What this covers: why vehicles are moving from signal-based CAN to service-oriented zonal designs, the automotive Ethernet physical layers and TSN features, the SOME/IP and SOME/IP-SD wire formats, the AUTOSAR Adaptive ara::com binding, a comparison with DDS, MQTT and CAN signals, security layers, OTA implications, and the failure modes that bite in production.

Context and Background

A modern premium vehicle can contain on the order of a hundred electronic control units (ECUs). Treat that figure as an industry rule of thumb rather than a measured constant, since it varies widely by model. Historically each function got its own ECU and a dedicated wire bundle, and the cabling harness became one of the heaviest and most expensive parts of the car. Domain architectures grouped ECUs by function (powertrain, body, infotainment, ADAS) behind domain controllers. Zonal architectures go a step further and group by physical location: a zone controller near each corner of the vehicle aggregates sensors and actuators locally and talks to a small number of central high-performance computers over an Ethernet backbone.

The signal-based paradigm of CAN does not scale into that picture. A CAN frame carries up to 8 bytes (64 with CAN FD, and 2048 with CAN XL) and identifies the content, not the sender or receiver. Every consumer is statically wired into the build: the signal matrix, a spreadsheet-like database of which frame carries which signal, is fixed at integration time. Adding a consumer means regenerating the matrix and often reflashing several ECUs. Our comparison of CAN FD, CAN XL and CANopen for industrial fieldbus covers where those buses remain the right answer, and for sensing and actuation near the edge of the car they still are.

Service orientation inverts the contract. A provider offers a service with a versioned interface; consumers find it by name at runtime, call its methods, subscribe to its events and read or write its fields. The provider can be moved to another ECU, replaced by a newer version, or run twice for redundancy without the consumer’s code changing. That is the property the software-defined vehicle needs, because features are developed, tested and deployed on different schedules by different teams and suppliers.

SOME/IP was designed in the early 2010s inside BMW and then standardised through AUTOSAR; the current specifications are published by AUTOSAR as the SOME/IP protocol specification and the SOME/IP Service Discovery protocol specification in the Foundation standard (see the AUTOSAR SOME/IP protocol specification). It sits alongside several alternatives. DDS, the Data Distribution Service from the Object Management Group, is a data-centric publish/subscribe middleware used in robotics and, increasingly, in automotive prototypes and the ROS 2 world. MQTT dominates the vehicle-to-cloud leg. And the AUTOSAR Adaptive Platform deliberately abstracts the choice behind its communication management API.

The Reference Architecture: Zonal E/E Over Automotive Ethernet

Direct answer: In a service-oriented vehicle, central compute nodes and zone controllers are joined by switched automotive Ethernet. Time-sensitive networking provides synchronised time and bounded latency. SOME/IP carries remote calls and events between services, SOME/IP-SD finds them at runtime, and gateways translate to CAN or LIN at the vehicle edge.

Figure 1: Zonal E/E architecture. Central compute talks SOME/IP over an Ethernet backbone to zone controllers, which gateway legacy CAN and LIN sensors and actuators.

The figure shows the layering. At the top sit one or two central high-performance computers (HPCs) hosting applications in the AUTOSAR Adaptive Platform or in POSIX-based software with a vehicle service framework. They are linked by a switched Ethernet backbone, typically with redundant paths on the safety-relevant branches, to zone controllers. Each zone controller owns local I/O: it speaks CAN FD, LIN and sometimes 10BASE-T1S to the sensors and actuators in its corner, and exposes them upward as services. The same physical box often acts as a Classic AUTOSAR ECU for the real-time I/O and a SOME/IP participant toward the backbone.

Why zonal helps, and what it costs

The argument for zonal design is not primarily about Ethernet. It is about wiring length, ECU count and software decoupling. Short local runs from sensor to zone controller replace long point-to-point looms, and consolidating dozens of small ECUs into a few zone controllers reduces hardware variants. Public statements from OEMs and suppliers describe meaningful harness weight and length reductions, but the numbers differ by programme and I will not quote a single percentage as fact.

The costs are real. A zone controller becomes a single point of failure for everything in its corner, so power distribution, redundancy and graceful degradation need design attention. Latency-sensitive loops, such as a brake-by-wire path, still want to be local or hard real-time. And the integration burden moves from wiring to software: you now have a distributed system with the full set of distributed-systems failure modes, in a product with a 15-year life and an ASIL (Automotive Safety Integrity Level) safety case.

Domain, zonal and distributed side by side

Property	Distributed (legacy)	Domain	Zonal
Grouping principle	One ECU per function	Functional domain	Physical location
Backbone	CAN, LIN, FlexRay	CAN FD plus Ethernet between domain controllers	Ethernet, switched, TSN
Software coupling	Signal matrix, static	Mixed signals and services	Service oriented, dynamic
Harness	Longest	Long	Shortest
Main risk	Integration and weight	Domain silos	Zone controller concentration

Most vehicles on the road in 2026 are hybrids of these columns. The practical question for a team is rarely “which one” but “which functions move to services first”. Infotainment, ADAS fusion, telematics and over-the-air update orchestration are the usual first adopters, while powertrain and chassis control typically remain signal-based inside their own safety islands, bridged by a gateway.

The gateway as translation boundary

A CAN-to-Ethernet gateway has to do more than copy bytes. It maps a periodic signal group onto either a SOME/IP event with a defined cycle, or onto an Ethernet PDU transport in AUTOSAR terms, which is a signal-based mapping that keeps CAN semantics on the wire. The first option gives service semantics but changes timing: the event cycle plus Ethernet queuing now adds to the CAN latency. The second preserves the signal view but forfeits discovery and subscription. A common compromise is to keep safety-relevant signals in the signal-based mapping and expose derived, lower-rate information as true services, such as “vehicle speed, filtered, 10 Hz”.

Automotive Ethernet: The Physical Layer and TSN Underneath

SOME/IP is only as predictable as the network beneath it, so the Ethernet specifics matter. Automotive Ethernet differs from office Ethernet in the physical layer, not the frame format: it uses a single unshielded twisted pair rather than four pairs, runs full duplex over that one pair, and is designed for the electromagnetic and temperature conditions of a vehicle.

The physical layers

PHY	IEEE amendment	Rate	Topology	Typical role
100BASE-T1	802.3bw	100 Mb/s	Point to point	Cameras, ECUs, early backbones
1000BASE-T1	802.3bp	1 Gb/s	Point to point	Backbone, ADAS compute, displays
2.5/5/10GBASE-T1	802.3ch	2.5, 5, 10 Gb/s	Point to point	High-resolution sensors, central compute links
10BASE-T1S	802.3cg	10 Mb/s	Multidrop or point to point	Replacing CAN-class buses with IP

The amendment numbers and rates are the part to check against the standards before you cite them in a design document; they match the IEEE 802.3 working group’s published amendment titles as I know them. The point to retain is the split. Point-to-point PHYs (100BASE-T1 upward) are switched, so the topology is a tree of switches. 10BASE-T1S is the interesting newcomer: it supports a shared multidrop segment and uses a mechanism called PLCA, physical layer collision avoidance, which hands out transmit opportunities in a round-robin fashion so that nodes get bounded access without CSMA/CD collisions. That lets an Ethernet node replace a CAN node at the edge of a zone, so the same IP stack, and therefore SOME/IP, can reach the last metre.

Time-sensitive networking features

Plain switched Ethernet is best-effort: a large infotainment frame can delay a control frame for one maximum-size transmission time at every hop. At 100 Mb/s a 1,500-byte frame occupies the wire for about 120 microseconds (1,500 bytes plus overhead, roughly 12,300 bits at 100 Mb/s), and several hops multiply that. For a 1 Gb/s link the same frame is about 12 microseconds. TSN, the IEEE 802.1 family of time-sensitive networking standards, adds the tools to bound that interference.

IEEE 802.1AS (gPTP) distributes a common time base using a generalised precision time protocol profile. Every shaper and every timestamped sensor depends on it.
IEEE 802.1Qav is the credit-based shaper, used to protect audio/video streams while limiting their burst.
IEEE 802.1Qbv is the time-aware shaper: gate control lists open and close per-queue gates on a repeating schedule, so a control stream gets an exclusive window.
IEEE 802.1Qbu with 802.3br adds frame preemption, interrupting a large low-priority frame to send a critical one.
IEEE 802.1Qci performs per-stream filtering and policing, so a misbehaving talker cannot flood a queue.
IEEE 802.1CB provides frame replication and elimination for reliability, sending a stream over two disjoint paths.

Selecting which of these a vehicle actually needs is the job of IEEE 802.1DG-2025, the TSN profile for automotive in-vehicle Ethernet communications, which per the IEEE 802.1 publication page specifies profiles for bounded-latency automotive in-vehicle bridged Ethernet networks. I could not retrieve its feature list from the public page, so I will not assert which options it mandates; read the standard before you commit to a design that assumes, for example, that Qbv is mandatory.

How SOME/IP maps onto this

SOME/IP traffic is ordinary UDP or TCP over IP, so the TSN machinery sees it through VLAN priority code points and, with Qci or stream reservation, through stream identification. A sensible mapping puts discovery and low-rate control calls in a mid-priority class, bulk events such as maps or diagnostics in best effort, and hard real-time streams into scheduled windows. The cardinal sin is to leave everything in one traffic class and discover under load that a software update download starves a steering-adjacent notification.

SOME/IP on the Wire: Header, Message Types and Transport

The SOME/IP header is intentionally small. The fields below are quoted from the AUTOSAR SOME/IP protocol specification (Foundation release R25-11); all values are big-endian.

Field	Size	Meaning
Message ID	32 bits	Service ID (16 bits) plus Method or Event ID (16 bits)
Length	32 bits	Bytes from the Request ID to the end of the payload
Request ID	32 bits	Client ID (16 bits) plus Session ID (16 bits)
Protocol Version	8 bits	Currently 0x01
Interface Version	8 bits	Major version of the service interface
Message Type	8 bits	Request, response, notification, error, and TP variants
Return Code	8 bits	0x00 is E_OK; errors use defined codes
Payload	variable	Serialised parameters

Figure 2: The 16-byte SOME/IP header. The Message ID selects service and method, the Request ID correlates responses, and the Message Type and Return Code encode the interaction style and outcome.

Reading the figure from the left: the Message ID is the dispatch key. The convention in the specification is that methods use Method IDs 0x0000 to 0x7FFF, while events and notifications use 0x8000 to 0x8FFF; the document marks this as a recommendation, not a rule. The Length field makes stream framing possible over TCP, where messages are concatenated and a receiver must find boundaries. The Request ID lets a client with several outstanding calls match each response to its request, because the provider copies the Request ID into the response.

Message types

The Message Type byte encodes the interaction pattern:

Type	Value	Pattern
REQUEST	0x00	Call that expects a response
REQUEST_NO_RETURN	0x01	Fire and forget call
NOTIFICATION	0x02	Event or field change pushed to subscribers
RESPONSE	0x80	Reply to a request
ERROR	0x81	Failure reply, return code must not be E_OK
TP variants	0x20, 0x21, 0x22, 0xA0, 0xA1	Same, with the TP flag set for segmented messages

The TP flag is the third-highest bit of the byte, 0x20. SOME/IP-TP exists because the specification recommends UDP payloads of 0 to 1,400 bytes, and larger payloads should use TCP or be segmented with TP. TP segmentation does not support reordering of segments, so it assumes a network that does not reorder, which a switched point-to-point tree usually satisfies.

Methods, events and fields

A method is a remote procedure call with request and optional response. A field combines up to three things: a getter method, a setter method and a notifier event that fires on change. An event is a notification sent to subscribers of an eventgroup, the unit of subscription. Grouping events matters because subscribing is a discovery-level operation, so you subscribe to a bundle such as “wheel speed events” rather than to each signal individually.

Serialisation

The header does not define payload serialisation. The payload is serialised according to a SOME/IP serialisation scheme in the AUTOSAR SOME/IP transformer (see the AUTOSAR SOME/IP transformer specification), which packs fixed-size types natively, prefixes dynamic arrays and strings with a length field, and aligns when configured to. The consequence is that the schema is not on the wire. Both sides must be built from the same interface description, which is why interface versioning (the Interface Version byte) and a disciplined interface catalog are non-negotiable. A consumer that decodes version 2 bytes with a version 1 layout will not fail loudly; it will produce plausible garbage.

Worked example: a service interface

The following is an illustrative service definition, not taken from any real vehicle, written in a Franca-like notation to show how the pieces fit.

// Illustrative only: VehicleSpeedService, service ID 0x1234, major version 1
interface VehicleSpeedService {
  version { major 1  minor 0 }

  attribute Float32 filteredSpeed { readonly }     // field: getter 0x0001, notifier 0x8001
  method setUnits { in { UInt8 unit } }            // method 0x0002
  method calibrate { in { UInt16 token } out { UInt8 status } }  // method 0x0003
  broadcast overspeed { out { Float32 speed } }    // event 0x8002 in eventgroup 0x0001
}

A client calling calibrate sends a REQUEST (0x00) with Message ID 0x1234_0003, its Client ID and an incrementing Session ID; the 16-byte header is followed by 2 payload bytes, so the Length field equals 8 (the remaining header bytes from the Request ID) plus 2, which is 10. The provider answers with a RESPONSE (0x80), the same Request ID, return code 0x00 and a one-byte payload, so its Length is 9. If the token is wrong the provider could return an ERROR (0x81) with a non-zero return code. Those byte counts follow directly from the header table above and are the kind of arithmetic worth asserting in an integration test.

SOME/IP-SD: How Services Find Each Other

Static addressing does not survive a software-defined vehicle, where a service might be hosted on whichever compute node is awake, healthy or updated. SOME/IP Service Discovery (SOME/IP-SD) solves this with a small protocol that itself rides on SOME/IP. Per the AUTOSAR service discovery specification, SD messages use Service ID 0xFFFF, Method ID 0x8100, Client ID 0x0000, Protocol and Interface Version 0x01, Message Type 0x02 (notification) and Return Code 0x00.

Figure 3: Service discovery sequence. A provider offers, a consumer subscribes to an eventgroup, the provider acknowledges, and notifications flow to the subscriber’s endpoint.

Entries and options

An SD message carries an array of 16-byte entries followed by an array of options. The entry types, from the specification, are:

Entry	Type value	Purpose
FindService	0x00	Consumer asks who offers a service
OfferService / StopOfferService	0x01	Provider announces, or withdraws with TTL 0
SubscribeEventgroup / StopSubscribeEventgroup	0x06	Consumer requests, or cancels, event delivery
SubscribeEventgroupAck / Nack	0x07	Provider accepts or refuses the subscription

Entries reference options, which carry the actual addressing: an IPv4 or IPv6 endpoint option (0x04 and 0x06) holds address, port and transport protocol, multicast options (0x14 and 0x16) describe a multicast group for event delivery, and an SD endpoint option (0x24 and 0x26) tells a peer which unicast address to use for SD itself. A configuration option (0x01) carries string key-value data. Because entries point at options by index, one endpoint option can be shared by many entries, which keeps offer messages small when a provider offers dozens of services from one socket.

TTL, reboots and sessions

The TTL field is 24 bits in seconds. A TTL of 0xFFFFFF means valid until reboot and 0 is reserved for the stop variants. A consumer that stops hearing offers lets the entry expire. This soft-state design is what makes discovery robust against a provider that crashes without sending a goodbye.

Reboot detection is the subtle part. SD messages have a Session ID that increments with each message and wraps to 1 (never 0), and a Reboot Flag that is set after a restart and cleared once the session counter wraps. A receiver infers that a peer rebooted if the old flag was 0 and the new one is 1, or if both are 1 and the new session ID is not greater than the old one. The state is kept separately for multicast and unicast, and per sender-receiver pair. The consequence for implementers: if you reset your session counter or flag handling incorrectly, peers will either miss your reboot, keeping stale subscriptions, or think you reboot on every message and tear subscriptions down.

The startup phases

Providers do not shout at once. The specification defines an initial wait phase with a random delay, a repetition phase in which offers are sent with exponentially growing intervals, and a main phase with a periodic cyclic offer. The random initial delay deliberately desynchronises a whole vehicle waking at the same moment. I could not retrieve the exact default parameter values from the excerpts I read, so treat any numeric default quoted elsewhere as something to confirm in the specification and in your stack’s configuration. In practice, these timers are tuned per project, and they dominate your time-to-ready after ignition.

Subscribing to events

To receive events, a consumer sends SubscribeEventgroup referencing its own endpoint options, one UDP and optionally one TCP, or a multicast option. The provider answers with an Ack, optionally pointing at a multicast group that it will use for fan-out, or with a Nack if it refuses. Matching is exact on service ID, instance ID, eventgroup ID and major version. The Nack path matters: it is how a provider says “I am not ready” or “version mismatch”, and a consumer that ignores it will wait forever for events that never come.

Service-Oriented Software: AUTOSAR Adaptive and ara::com

The AUTOSAR Adaptive Platform exposes services to applications through ara::com, the communication management API. According to the AUTOSAR platform design explanation, communication management separates a language binding, how an application sees a service in C++, from a network binding, how the service reaches the wire. It lists SOME/IP, DDS and IPC among the supported network bindings, plus signal-based variants (see the AUTOSAR Adaptive platform design explanation). The interface between the two is described as private, which is an honest warning: it keeps application source portable, but vendor stacks are not interchangeable at the binding boundary.

An application defines a service interface in the AUTOSAR meta-model (ARXML); a generator produces a proxy class for consumers and a skeleton class for providers. The consumer calls FindService, receives a handle, constructs a proxy, calls methods that return futures and subscribes to events with a receive handler. A provider derives from the skeleton, implements the methods and calls OfferService. Underneath, the network binding uses SOME/IP-SD to publish or discover and SOME/IP to carry the calls.

The same document describes configurations from fully static (the service endpoints are in the manifest, no discovery in application code) to full dynamic discovery in the application. Static configuration is useful where determinism and fast start-up matter more than flexibility, such as safety-relevant services that must be ready within a bounded time after wake-up.

A runnable decoder

The sketch below parses a SOME/IP header and an SD entry in plain Python. It is a teaching tool built from the field layout above, useful for packet captures in a lab; it is not a stack.

import struct

MSG_TYPES = {0x00: "REQUEST", 0x01: "REQUEST_NO_RETURN", 0x02: "NOTIFICATION",
             0x80: "RESPONSE", 0x81: "ERROR", 0x20: "TP_REQUEST",
             0x21: "TP_REQUEST_NO_RETURN", 0x22: "TP_NOTIFICATION",
             0xA0: "TP_RESPONSE", 0xA1: "TP_ERROR"}
SD_ENTRY = {0x00: "FindService", 0x01: "OfferService",
            0x06: "SubscribeEventgroup", 0x07: "SubscribeEventgroupAck"}

def parse_someip(buf: bytes) -> dict:
    if len(buf) < 16:
        raise ValueError("short header")
    svc, meth, length, client, session, proto, iface, mtype, rc = \
        struct.unpack(">HHIHHBBBB", buf[:16])
    if len(buf) < 8 + length:
        raise ValueError("truncated: length says %d, have %d" % (length, len(buf) - 8))
    msg = {"service": hex(svc), "method": hex(meth), "client": client,
           "session": session, "proto": proto, "iface": iface,
           "type": MSG_TYPES.get(mtype, hex(mtype)), "rc": rc,
           "payload": buf[16:8 + length]}
    if svc == 0xFFFF and meth == 0x8100:
        msg["sd"] = parse_sd(msg["payload"])
    return msg

def parse_sd(p: bytes) -> list:
    flags = p[0]                       # bit7 reboot, bit6 unicast
    (n_entries,) = struct.unpack(">I", p[4:8])
    entries = []
    for off in range(8, 8 + n_entries, 16):
        e = p[off:off + 16]
        etype, i1, i2, nopt = struct.unpack(">BBBB", e[:4])
        svc, inst, major_ttl, minor = struct.unpack(">HHII", e[4:16])
        ttl = major_ttl & 0xFFFFFF
        entries.append({"entry": SD_ENTRY.get(etype, hex(etype)),
                        "service": hex(svc), "instance": hex(inst),
                        "major": major_ttl >> 24, "ttl": ttl,
                        "stop": ttl == 0, "reboot": bool(flags & 0x80)})
    return entries

if __name__ == "__main__":
    # Illustrative REQUEST for service 0x1234 method 0x0003 with 2 payload bytes.
    raw = struct.pack(">HHIHHBBBB", 0x1234, 0x0003, 10, 0x0001, 0x0007,
                      1, 1, 0x00, 0x00) + b"\xBE\xEF"
    print(parse_someip(raw))

The Length arithmetic in the example reproduces the rule stated earlier: it counts from the Request ID onward, so a 2-byte payload yields 8 + 2 = 10. If your own decoder disagrees with a capture, the Length field is the first place to look.

DDS vs SOME/IP, MQTT and CAN Signals

The choice of middleware is less a technology contest than a question of which layer of the vehicle you are standing in. Each option optimises something different.

Figure 4: Where each communication paradigm fits. CAN signals at the edge, SOME/IP between ECUs and compute, DDS in data-centric compute domains, MQTT across the cloud boundary.

SOME/IP is a thin, method-oriented protocol. The wire format is compact, the schema lives outside the wire, discovery is minimal and quality of service (QoS) is whatever the transport and the TSN configuration provide. Its strength is that the entire protocol fits in an ECU with modest memory and that its behaviour is easy to reason about at the byte level.

DDS is data-centric. The Data Distribution Service, standardised by the Object Management Group with the RTPS wire protocol, models a global data space of typed topics. Publishers and subscribers are matched by topic and type, discovery is built in, and a rich QoS vocabulary controls reliability, durability, deadlines, history depth and liveliness per endpoint. That makes DDS well suited to sensor-fusion pipelines where many nodes consume the same streams with varied needs, and it is the transport behind ROS 2. The price is a larger footprint, more configuration and more behaviour to understand, such as discovery traffic scaling with participants.

MQTT is a broker-based publish/subscribe protocol over TCP, designed for constrained and unreliable links. It is the default for the vehicle-to-cloud leg because brokers handle intermittent connectivity, retained messages and fan-out to many cloud consumers. Inside the vehicle, a broker is a single point of failure and an added hop, which is why it rarely replaces SOME/IP for control traffic. For the telematics side of the picture, see our article on EV architecture, battery and telematics.

CAN signals remain unbeatable where a periodic value with hard, tiny latency bounds must reach a known set of consumers.

Criterion	CAN / CAN FD signals	SOME/IP	DDS	MQTT
Model	Signal broadcast	RPC, events, fields	Data-centric topics	Broker pub/sub
Discovery	None (static matrix)	SOME/IP-SD	Built-in (RTPS)	Broker address only
QoS	Priority arbitration	Transport + TSN	Rich per-endpoint QoS	Three delivery levels
Footprint	Smallest	Small	Larger	Small to medium
Typical home	Zone edge, powertrain	ECU to ECU, AUTOSAR	Compute, ROS 2, fusion	Vehicle to cloud
Weak point	Rigid, low bandwidth	Schema outside wire	Tuning, discovery load	Broker dependency

In short, treat the debate of DDS vs SOME/IP as a boundary-placement problem. Many production programmes run SOME/IP across the AUTOSAR domain and DDS in the high-performance autonomy stack, with a gateway or an ara::com DDS binding between them. The AUTOSAR design listing DDS beside SOME/IP as network bindings is itself evidence that the industry expects coexistence, not a winner.

Security: Securing a Service-Oriented Network

Moving from a closed bus to switched IP removes security-by-obscurity and adds a larger attack surface. SOME/IP itself provides no authentication or encryption; the protocol defines no such fields in the header. Protection comes from layers around it.

Link layer: IEEE 802.1AE MACsec encrypts and authenticates Ethernet frames hop by hop. It protects against a tap on a cable or a rogue device, but it terminates at each switch that does not support it, and key distribution (via 802.1X or MKA) needs infrastructure.
Network layer: IPsec or TLS/DTLS. TLS for TCP-based services and DTLS for UDP give end-to-end protection between endpoints regardless of switches. The cost is handshake latency and CPU on small ECUs.
Message layer: AUTOSAR SecOC. Secure Onboard Communication adds a truncated message authentication code and a freshness value to a PDU. It was designed for CAN, and Ethernet PDU mappings exist; I have not verified how consistently suppliers deploy it for SOME/IP payloads, so confirm the support in your stack.
Detection: an intrusion detection system (IDS) observes traffic for anomalies, such as an SD offer from an unexpected address or a subscription flood. AUTOSAR publishes IDS specifications; deployment maturity varies by OEM.
Network segmentation and filtering: VLANs, switch ACLs and per-stream policing (802.1Qci) confine a compromised node.

Two concrete SD threats deserve attention. First, because offers are accepted from the network, a malicious node can offer a service ID before the real provider does, hijacking consumers. Mitigations are static configuration of trusted provider addresses, MACsec so only authenticated devices can send, and an IDS rule for duplicate offers. Second, subscribe floods can exhaust a provider’s subscriber table. Bounded tables with rejection via Nack, plus Qci policing, turn that into a contained failure.

Regulation frames all of this. UN Regulation No. 155 on cybersecurity management systems and ISO/SAE 21434 on cybersecurity engineering are the reference points for type approval and process; neither prescribes SOME/IP-specific controls, so your threat analysis must map the controls above to concrete threats.

OTA Updates and the Service Lifecycle

Over-the-air updates are the reason service orientation exists commercially, and they stress SOME/IP in specific ways. When a provider is updated, its service restarts; consumers see the offer expire or a StopOffer, and must handle the gap. If the interface major version changes, a consumer built against version 1 will not match a version 2 offer, because the major version participates in SD matching. That is a feature: it prevents silent misuse. But it demands a compatibility strategy.

A workable policy is to treat minor versions as backward-compatible additions (new methods and events appended, existing semantics preserved) and to run old and new major versions side by side during rollout, offering two instances with different versions. The consumers migrate on their own schedule, and the old offer is retired when telemetry shows no subscribers. Rollback is the mirror image: because both versions exist briefly, a failed update falls back without a bricked consumer.

The update mechanism itself deserves rigour. A robust OTA design verifies signed metadata, uses A/B partitions, and defends against rollback and freeze attacks; see our comparison of SUIT, Uptane, Mender, RAUC and SWUpdate for the trade-offs. The interaction to design explicitly is sequencing: updating a provider and its consumers in the wrong order, or while the vehicle is moving, can produce a state where services are offered but no compatible consumers exist, so orchestration should be a first-class component, not a script.

Trade-offs, Gotchas, and What Goes Wrong

Service-oriented networks fail differently from signal buses. A missing CAN frame is visible as a stale signal within one cycle. A missing service is a silent absence that may only surface when the feature is used. The failure modes below are the ones that recur in integration.

Service discovery races. At ignition dozens of ECUs boot at different speeds. A consumer that sends FindService before the provider has started will get its answer at the next cyclic offer, so time-to-ready depends on SD timers. Worse, a consumer that subscribes before the provider’s socket is ready can have its subscription acknowledged but the first events dropped. The remedies are to make consumers tolerant (re-read field values after subscription ack, rather than assuming the first event arrives), to size repetition timers to your boot-time budget and to use static configuration for the few services that must be ready fast.

Multicast storms. SD uses multicast for offers, and event fan-out can use multicast groups. On a switch without IGMP snooping, multicast floods every port, and on a low-rate link such as 10BASE-T1S a modest multicast stream can consume the segment. A second variant is the offer storm after a gateway reset, when every provider repeats its offers simultaneously. The random initial wait exists to prevent this, and disabling or shrinking it to save boot time reintroduces the storm. Configure snooping and multicast filtering, and measure offer traffic during a worst-case restart.

Time synchronisation loss. TSN gate schedules assume a shared clock. If gPTP loses its grandmaster or a path breaks, nodes drift, windows misalign and a scheduled stream may land in a closed gate. Define explicit behaviour: holdover duration, fallback to a safe priority mapping and a diagnostic trouble code. Test by unplugging the grandmaster during a drive-cycle simulation, not only by reading the configuration.

Reboot detection errors. As described, the SD session and reboot flag logic has to be right. A stack that resets its counter on a soft restart without setting the flag creates a ghost state in which peers retain a stale subscription and the provider never delivers events. Include reboot-flag assertions in interoperability tests between suppliers.

UDP size and fragmentation. A payload above the roughly 1,400-byte recommendation will fragment at IP level unless TP or TCP is used. Fragments are lost together: with a 1% packet loss and a three-fragment message, the message loss rate is close to 3% (illustrative arithmetic: 1 – 0.99^3). TCP adds head-of-line blocking after loss, which is a latency problem for events. Pick per service, and keep event payloads small.

Schema drift. Because the schema is off the wire, two suppliers’ builds can disagree silently. Pin interface descriptions in a single repository, generate code from them and fail the build on an unversioned change.

Latency budgeting. Service layers add up: serialisation, the stack, queuing at each switch, the receiver’s scheduler. A budget worked at 1 Gb/s (illustrative): two switch hops at roughly 12 microseconds of worst-case blocking each, serialisation of a 200-byte frame at about 2 microseconds, plus tens to hundreds of microseconds in the software stack. The wire is rarely the dominant term; the OS scheduler and the middleware usually are. If your control loop budget is 1 ms, measure the stack with hardware timestamps before blaming Ethernet.

Organisational anti-pattern. Treating SOME/IP as a drop-in replacement for CAN signals (“one event per signal at 10 ms”) gives you more traffic and the same coupling, with extra failure modes. Services should expose meaningful capabilities, not mirrored signals.

Practical Recommendations

Start from the function, not the protocol. List the interactions a feature needs and classify each: a periodic control value with hard latency bounds belongs on a signal path or a TSN-scheduled stream; an on-demand capability with arguments belongs behind a method; a state that others need to track belongs in a field with a notifier; and bulk data belongs on TCP or a separate channel.

Fix the contract early. Put interface descriptions under version control with a compatibility policy and generate both skeleton and proxy code from them. Decide the major-version coexistence rule before the first OTA, not after.

Budget the network deliberately. Assign traffic classes, decide which streams need scheduled windows or shaping, and test with the gPTP master disabled. Treat the TSN profile, whichever you adopt, as a configuration artifact reviewed like code.

Secure in layers. Use MACsec on links where the hardware supports it, authenticate at message or session level for critical services, restrict who may offer services, and instrument an IDS for discovery anomalies.

Test the boot, not just the steady state. Most field issues appear during wake-up, partial restarts and mixed-version fleets.

[ ] Every service has a versioned interface description and an owner.
[ ] SD timers (initial wait, repetition, cyclic offer, TTL) are documented and justified against the boot budget.
[ ] Reboot flag and session ID behaviour verified in a multi-supplier interoperability test.
[ ] Traffic classes, VLAN priorities and any gate schedules are defined and reviewed.
[ ] IGMP snooping or multicast filtering is configured on every switch.
[ ] Time sync loss behaviour is specified and tested.
[ ] Payloads above about 1,400 bytes use TCP or SOME/IP-TP deliberately.
[ ] Security layers (MACsec, TLS/SecOC as applicable, IDS) are mapped to the threat analysis.
[ ] OTA plan covers mixed-version operation and rollback.

Frequently Asked Questions

What does SOME/IP stand for and what is it used for?

SOME/IP stands for Scalable service-Oriented MiddlewarE over IP. It is an AUTOSAR-standardised protocol that lets vehicle ECUs and compute nodes call each other’s methods, subscribe to events and read or write fields over Ethernet. Its companion, SOME/IP-SD, handles runtime service discovery. It is used between domain controllers, zone controllers and central computers in service-oriented vehicle architectures, typically carried over UDP or TCP on automotive Ethernet.

Is SOME/IP a replacement for CAN?

Not generally. CAN and CAN FD remain the right fit for low-cost, deterministic, periodic signals at the edge of a zone, and many vehicles will use them for years. SOME/IP complements CAN by connecting higher-level compute nodes with richer interactions. A gateway or zone controller typically translates between the two. The shift is architectural: new features move to services, while legacy and safety-critical loops keep their signal-based paths.

What is the difference between DDS and SOME/IP?

DDS is data-centric, with a global typed data space, built-in discovery and an extensive per-endpoint QoS model, which suits sensor-fusion and robotics stacks such as ROS 2. SOME/IP is method-oriented, lighter and tied to the AUTOSAR ecosystem, with QoS delegated to the transport and TSN. Many vehicles use both, and AUTOSAR Adaptive lists both among its network bindings, so the choice is about where each boundary sits.

Does SOME/IP provide security?

No. The protocol defines no authentication or encryption fields, so security is added around it: MACsec at the link layer, TLS or DTLS at the transport, message authentication such as SecOC where supported, plus filtering and intrusion detection. Service discovery needs special care because an attacker who can send an offer could impersonate a provider. Design the protection from your threat analysis rather than assuming the protocol covers it.

Which Ethernet speeds does a software-defined vehicle use?

Several coexist. 10BASE-T1S (IEEE 802.3cg) serves edge nodes, 100BASE-T1 (802.3bw) serves many sensors and ECUs, 1000BASE-T1 (802.3bp) forms most backbones, and multi-gigabit variants (802.3ch) connect high-bandwidth sensors and central compute. The exact mix depends on the vehicle programme, so verify rates against the amendment text and your supplier datasheets before sizing a network.

How does a service find another service at runtime?

Through SOME/IP-SD. Providers multicast OfferService entries with a time-to-live, consumers can send FindService, and consumers subscribe to eventgroups with SubscribeEventgroup, receiving an Ack or Nack. Entries expire if offers stop arriving, so crashed providers disappear automatically. A reboot flag and session counter let peers detect restarts, and startup timers desynchronise a vehicle waking all at once.