ContiMech
Robotics & Automation Engineering

Capabilities / System engineering / Communication protocols

System engineering · communication protocols

Communication protocol engineering

We engineer the communication layer as a system contract: the byte on the wire, the state machine behind it, the timing and fault behaviour around it, and the specification that keeps both ends implementable and testable.

CAN / CAN FDRS-485 / USB / IPE2E & securityICD & conformance
Protocol data unit and message catalogue diagram

A protocol is not only a frame format. We define framing, message semantics, roles, retries, freshness, timing, fault response, security boundaries, recovery, and verification as one coherent interface design.

What we design

Frame contractDelimiting, header fields, payload typing, units, endianness, integrity trailer, reserved fields, and versioning rules.
BehaviourCommand/response semantics, role arbitration, acknowledgements, retries, duplicate handling, idempotency, and terminal failure states.
TimingSerialization, arbitration, scheduler and task periods, host latency, timeout derivation, bus load, and margin.
Data protectionCRC selection, E2E Data IDs, alive counters, freshness, replay protection, CMAC/HMAC or authenticated encryption where justified.
Failure managementStale data, node loss, resynchronisation, bus-off recovery, safe-state entry, rate limiting, and diagnostics counters.
VerificationConformance suites, fault injection, replay and corruption tests, long-run soak, and HIL scenarios derived from the specification.

From topology to receiver decision

HMI and Control Board protocol topology
Interface topology and authority boundary from the public HMI–CB reference ICD.
Receiver validation pipeline
Validation pipeline: identifier and message contract, E2E checks, freshness/authentication, then application handling.

Security is separated from integrity

IntegrityCRC and E2E checks detect corruption, stale buffers, wrong message delivery, and sequence faults across the software path.
AuthenticityState-changing services can use CMAC/HMAC with freshness values to prevent forgery and replay.
ConfidentialityEncryption is added only where disclosure is a credible loss and key lifecycle is actually solved.

Specification is an executable asset

We keep the message catalogue machine-readable and version-controlled so embedded headers, serializers/parsers, host-side tooling, and human-readable ICD tables can be generated from one reviewed source. This avoids a second hand-maintained message list drifting away from code.

Protocol deployment and key provisioning diagram
Deployment view including firmware, configuration, security peripheral, and end-of-line key provisioning.

Public reference: HMI ↔ Control Board over CAN

Physical / linkClassic CAN, 11-bit identifiers, 500 kbit/s, isolated nodes, explicit sample point and termination requirements.
Application / E2EFixed PDU, safety/command/response/telemetry classes, Data-ID CRC, alive counter, segmented configuration transfer.
Timing / FDIRSafe-stop latency budget, periodic telemetry, link-loss detection, session release, bus-off recovery, and per-message error counters.
Open reference case studyDiscuss a protocol task