Delivering reliable automotive software means balancing safety requirements with rapid development cycles. With RemotiveLabs, teams skip manual E2E protocol wiring and long integration phases - E2E protection is automatically applied the moment a signal database is loaded. This enables developers to focus on building value, not low-level protocol details, speeding up everything from first test to vehicle integration. As your design evolves, our infrastructure-as-code approach ensures your E2E setup is always versionable and repeatable, whether you’re developing in simulation, CI/CD, or with real hardware.

‍

How E2E protection works in the RemotiveLabs platform

AUTOSAR E2E is a detection method for protecting against message corruption, loss, repetition, and reordering using CRC checksums, counters, and unique Data IDs. When available in the signal database or platform definition, RemotiveLabs automates E2E additions in messaging removing manual and tedious aspects during ECU software development:

• Plug & play with common formats: Supports DBC, ARXML, and more.
• Easily extendable: If profile information is missing, you can easily extend the database by adding metadata in a simple JSON format, as described in Meta Database JSON Schema and shown in an example in GitHub.
• Automatic frame encoding: RemotiveLabs encodes, verifies, and protects messages at runtime.
  ‍

E2E handling: Python example in RemotiveTopology

By using RemotiveTopology and our related tools, E2E protection is handled for you, so you can focus on the signals that bring application value. Whether you’re using a behavioral model or a mock, RemotiveTopology automatically manages both sporadic and cyclic frames, applying the correct CRC and counter.

Simple Python example on how RemotiveTopology automatically handles E2E for cyclic frames sent from an ECU named “MYECU”:

from __future__ import annotations

import asyncio

from remotivelabs.broker import BrokerClient
from remotivelabs.topology.behavioral_model import BehavioralModel
from remotivelabs.topology.namespaces import filters
from remotivelabs.topology.namespaces.can import CanNamespace, RestbusConfig

async def main():
   async with BrokerClient(url="http://127.0.0.1:50051") as broker_client:
       can0 = CanNamespace(
           name="can0",
           broker_client=broker_client,
           restbus_configs=[
               RestbusConfig([filters.SenderFilter(ecu_name="MYECU")]),
           ],
       )
       async with BehavioralModel(
           "MYECU",
           namespaces=[can0],
           broker_client=broker_client,
       ) as bm:
           await bm.run_forever()

if __name__ == "__main__":
   asyncio.run(main())

‍

Output from above Python example shows candump trace from the behavioral model, demonstrating how E2E protection is automatically applied to CAN messages:

(1756821715.061683) can0 700#E9F00019000000F0
(1756821715.551717) can0 700#B4F10019000000F0
(1756821716.051896) can0 700#53F20019000000F0
(1756821716.552009) can0 700#0EF30019000000F0
(1756821717.051951) can0 700#80F40019000000F0
(1756821717.551849) can0 700#DDF50019000000F0
(1756821718.051975) can0 700#3AF60019000000F0
(1756821718.552391) can0 700#67F70019000000F0
(1756821719.052150) can0 700#3BF80019000000F0
(1756821719.551915) can0 700#66F90019000000F0
(1756821720.051983) can0 700#81FA0019000000F0
(1756821720.552026) can0 700#DCFB0019000000F0
(1756821721.051929) can0 700#52FC0019000000F0
(1756821721.551958) can0 700#0FFD0019000000F0
(1756821722.051830) can0 700#E8FE0019000000F0
(1756821722.552050) can0 700#E9F00019000000F0

The CRC appears in the first byte and the counter is placed in the lower nibble of the second byte. Looking at the counter we can see that it cycles between 0 and 14 suggesting that this frame is using E2E profile 1. The rest of the signals have default values from the signal database, but these can also be changed in the restbus.

‍

Developer-centric infrastructure as code for SDV development

With RemotiveTopology it is easy to test your ECU using the platform definition. The same approach as described for E2E above also applies for SecOC protection data. Learn more about RemotiveTopology:

• RemotiveTopology product page
• RemotiveTopology Documentation
• Meta Database JSON Schema 
• Sample E2E Configs and Meta Database on GitHub

Visit our our E2E docs page for profile overviews or contact support@remotivelabs.com if you have questions or need additional E2E profiles, we are constantly expanding our support with customer needs. 

‍

‍

‍