SOME/IP¶
Automotive service-oriented middleware protocol for RPC-like and event-based communication over IP.
| Status | Examples | Runtime example | Source posture |
|---|---|---|---|
draft-structure-only |
synthetic/passive |
docs-only |
atlas metadata plus public/tooling cross-checks |
Identity¶
Automotive service-oriented middleware protocol for RPC-like and event-based communication over IP.
What This Protocol Teaches¶
- SOME/IP is where vehicle communication starts looking like service software.
- It teaches how to inspect service ID, method ID, message type without mistaking field extraction for meaning.
- It keeps observer inference separate from system truth.
Operational Context¶
SOME/IP appears in automotive contexts and is modeled in the atlas at the application layer(s). The binder treats it as an inspection surface: what evidence appears, what timing matters, and what outside authority is required before assigning meaning.
Draft status
draft-structure-only: this is not yet a final-copy binder page. It has an atlas-grounded teaching hook and source notes, but still needs a stronger worked trace, page-specific ambiguity case, and reviewer-validated visual before promotion.
A Concrete Artifact¶
# synthetic SOME/IP message
service=0x1234 method=0x0421 client=0x0100 session=0x0002 len=8
Synthetic
Synthetic offline sample for explanation; not a real operational trace or live-system instruction.
Worked Decode¶
- Treat
service=0x1234andmethod=0x0421as service-interface evidence in a synthetic message. client=0x0100andsession=0x0002are correlation fields, not permanent ECU identity.len=8bounds the message body but does not describe its application schema.- Request, response, and event labels remain observed-message roles rather than instructions to invoke a service.
Field Layout / Anatomy¶
| Element | Shape | Inspection meaning |
|---|---|---|
| service ID | artifact-specific evidence | Inspect with timing and source context before naming meaning. |
| method ID | artifact-specific evidence | Inspect with timing and source context before naming meaning. |
| message type | artifact-specific evidence | Inspect with timing and source context before naming meaning. |
| request/response/event | artifact-specific evidence | Inspect with timing and source context before naming meaning. |
| semantic authority | external source | Dictionary, profile, map, or integration document that turns evidence into named meaning. |
| timing context | cadence / gap / slot / timestamp | Freshness and ordering evidence for observer reconstruction. |
Visual Model¶
Timing And Authority¶
Repeated service, method, client, and session fields can support correlation and cadence claims within an offline record. They do not establish which ECU owns the service, whether a response was accepted, or what the payload means.
Semantic authority
Service and method semantics come from the applicable AUTOSAR interface description and its provenance. Matching numeric IDs across captures is not enough to establish that the same deployed interface is present.
Failure And Ambiguity¶
- Service and method IDs need ARXML or interface authority.
- Client/session IDs correlate messages but do not prove ECU identity.
- Observed request/response/event wording must stay passive and synthetic.
Observer Lesson¶
A passive observer can correlate synthetic request-, response-, and event-shaped records by visible header fields. It cannot prove endpoint identity, service availability, application acceptance, or physical state from those correlations.
Python Model¶
No current runtime example is claimed for this draft page. Keep reader claims at the artifact and source level until a separate implementation plan adds a tested model.
Local Teaching Notes¶
Simplification
The artifact and diagrams are synthetic teaching material. The page intentionally omits conformance timing tables, electrical design detail, proprietary configuration, and exhaustive standard behavior.
Source Confidence¶
Source confidence is medium for scope and terminology, with semantic claims limited to public metadata, public source notes, and synthetic teaching artifacts.
Source Notes¶
| Field | Value |
|---|---|
| Governance tier | Tier 2 Field Note |
| Canonical source status | yes |
| Public explainer status | no |
| Open-source tool status | yes |
| Sample-data status | none listed; use synthetic teaching artifacts |
| Confidence | medium |
| Citation specificity | document-metadata-level |
| Canonical source(s) | AUTOSAR Classic Platform standards (AUTOSAR; AUTOSAR Classic Platform; public-web; metadata-only) |
| Public explainer/tooling source(s) | none listed in atlas |
| Open-source tool references | Scapy automotive layers: automotive layer structure and packet inspection docs Wireshark: Protocol dissectors and PCAP analysis |
References¶
Public Sources¶
- AUTOSAR
- AUTOSAR Classic Platform standards — canonical-standard.
- Tooling references
- Scapy automotive layers — automotive layer structure and packet inspection docs.
- Wireshark — Protocol dissectors and PCAP analysis.