Signal lists that check themselves: E/E architecture and interface management in Polarion

A Tier-1 supplier rarely owns the signal list it works to. The carmaker sends it as a spreadsheet, then sends it again a few weeks later with changes, and somebody reconciles it by hand against the supplier's own software interfaces. With a few hundred signals that is tedious. With several thousand, across many control units, networks and vehicle variants, it is where interface mismatches slip through to the test bench.

We built a demo project to show how this discipline looks inside Siemens Polarion ALM with Powersheet, the traceability app for Polarion. It holds the whole chain as linked work items. Every screenshot below is the project itself, not a mock-up.

One chain, as work items

The demo models a small electric vehicle: five networks (CAN FD, classic CAN, LIN and automotive Ethernet), twelve ECUs, around thirty software and hardware components and about three hundred signals in fifty messages.

Functions are allocated to components. Each component is deployed on an ECU and has interface ports: its own expectation of a signal, with direction, data type, unit and range. Each port maps to a signal, the signal belongs to a message, and the message is carried by a network. Signals, ECUs and functions record the vehicle variants they exist in.

Each network's signal list is a Polarion document, the interface control document (ICD) for that network. Each message is a section, and its signals sit beneath it.

A signal database you work in

The signal database is a Powersheet: every signal of every network in one grid, with data type, unit, scaling, bit length, range and variants. It is not a report. It is a spreadsheet you work in, and every row is a live work item.

Because the rows are linked, the sheet shows what a spreadsheet cannot know on its own: the transmitter and the receivers of each signal, derived from the component ports, and a Findings column worked out from those links on the server. Here, the front-left wheel speed goes out in km/h while the cruise controller that reads it expects m/s. The row says so.

The Signal Database in Powersheet: the front left wheel speed signal flagged with a unit finding, the cruise controller expects m/s

Fixing it happens where the data lives: change the cell, save, and the finding clears. New signals are created from the toolbar of a second sheet, the messages of each network, and are filed in that network's ICD document.

Checks a spreadsheet cannot run

A consistency report runs the same rules across the whole project. It is rendered from the work items each time it opens; nobody maintains it.

  • Unit and data type between a signal and every component that reads it.

  • Range against bit length: a maximum value that cannot be encoded with the signal's bits, factor and offset.

  • Signals without a receiver, transmitted into the void or waiting for an interface that was never modelled.

  • Variant gaps: a signal that exists in a variant its sending ECU is not built for.

  • Network reachability: a receiver on an ECU that is not connected to the network carrying the message.

  • Duplicate message identifiers on one network.

The Consistency Report: signals, findings and message ID collisions, with the number of findings for each check

Who talks to whom

An N² matrix sets every ECU against every other and counts the signals between them, from the interface links. Under the matrix, each count lists the signals behind it. The gateway column is the busiest, as it should be: it carries everything that crosses from one network to another.

The N² matrix of the demo vehicle: every ECU against every other, with the number of signals each sends to each

A release, and what changed

When an ICD release is agreed with the carmaker, the documents are baselined in Polarion. A diff page compares a release with the current state, or two releases with each other, signal by signal and field by field: what was added, what was removed, and which field of which signal changed, with the old and the new value.

The ICD diff between release 1.0 and the current state: one signal added on the chassis network, vehicle speed changed from 12 to 16 bits

That is the list an ICD review needs, instead of rereading every row.

What this demo does not do

The demo shows the discipline inside Polarion. It does not import an OEM signal list from Excel, AUTOSAR ARXML or DBC files, and it does no timing or bus-load analysis. Where the E/E architecture is authored in a dedicated tool such as PREEvision or Capella, that tool stays the source for it.

Talk to us

If your signal lists live in spreadsheets and your architecture or requirements already live in Polarion, we would like to show you the project and hear how your ICD releases work today. Book a meeting, or read more about Powersheet.

The Best Way to Know Is to Try

Get hands-on with traceability from requirements to verification in a live Polarion demo, or let our experts walk you through it.

Instant access with no installation needed

Full feature access with real context

Get expert support if you want it

The Best Way to Know Is to Try

Get hands-on with traceability from requirements to verification in a live Polarion demo, or let our experts walk you through it.

Instant access with no installation needed

Full feature access with real context

Get expert support if you want it

The Best Way to Know Is to Try

Get hands-on with traceability from requirements to verification in a live Polarion demo, or let our experts walk you through it.

Instant access with no installation needed

Full feature access with real context

Get expert support if you want it