Feature Configuration

The FT-COM layer has several features that need configuration. A selection of these features is presented here, and relevant aspects regarding configuration and automatic code generation are discussed.

Subsystem Replication

A subsystem can be regarded as a set of tasks that take some input and produce some output. Each task is part of exactly one subsystem, but each subsystem may contain as many tasks as necessary. Several subsystems may be executed — independently of each other — on one host. A subsystem may also be executed simultaneously on more than one host (replicated subsystem). The first step toward fault tolerance can thus be achieved by replicating functionality, i.e., by replicating a subsystem.

The FT-COM needs to know how often a subsystem is replicated, and on which hosts these replicated subsystems run. It is expected that the FT-COM layer delivers a consistent view of the entire cluster regarding the value of a message, and provides diagnostic data to assess the “quality” of the provided data.

The Replica-Deterministic Agreement (RDA) Function

Development Tools 469 The receiver of a messagemthat is sent by a subsystemF, which is replicated with a replication degree ofn, will in fact receive several message instances orraw values miof that message — one from eachFi that is active. But what is really wanted is the “correct” or “agreed” value. Therefore, the receiver needs to take the incoming instancesmi, run a function on them, and generate a single valuemthat will then be used for the application:

m=rda(m₁, m₂, . . . m_r) (15.21) The upper limit forris the replication degreen, which applies when all replicas ofF are active, the lower limit is zero.rda, theagreement function, must therefore be able to consistently handle an input vector of any length from zero ton. It must also be deterministic [258]. Several RDA functions exist and are selectable for the FT-COM, depending on the type of the subsystem (fail-safe or fail-consistent) [343].

Instead of encoding an algorithm that works for anyn, it might yield a better perfor-mance to insert different implementations of the same algorithm into the FT-COM code, depending onn.

Application code that accesses the messagemshould never need to access the individual instancesmi, and can therefore be “ignorant” of the replication degree of the sender ofm. A change of this replication degree only requires an update of the FT-COM layer, but not of the application itself.

Reintegration with H-State

Each (application) task generally takes some input, performs some function on it and produces a result as output; both input and output are messages. Furthermore, the task can contain static internal data that influences the computation and hence the output. The set of this internal data is calledh-state.

For fast reintegration and enhanced robustness of the whole system, it might be necessary for a replicated instance of a subsystem to know this h-state of its partner instances. The network designer has to define a global message (“h-state message”) that contains this information. Now the output can be considered solely a function of the input, no “hidden” data is involved anymore. For performance reasons, these h-state messages should only be received and processed whenno valid h-state is currently present. The generated FT-COM layer needs to monitor the h-state, and to provide it when necessary.

Receiver Status

From the RDA mechanism, thenumber of correctly received message copies can immediately be derived by setting up a counter that is initialized with zero at the be-ginning of the message transmission interval, and increased by one for each message copy that is received correctly, finally givingr. This counter is called thereceiver statusof a messagem. The receiver status is useful for several RDA functions. For example, the application software can use the receiver status to derive confidence information on how “good”mis. Another example is averaging: All validm_i are summed up, and the result is divided by the receiver status. It would be incorrect to

470 Time-Triggered Communication

divide the sum byn, because in case of a failure of one or more replicas ofF, the sum would contain less thanncomponents.

In a programming language that treats the number zero as the Boolean equiv-alent of “false” and any number other (or at least greater) than zero as “true,” the receiver status can also be queried like a Boolean flag that yields “true” if the mes-sage is present, meaning that it was received correctly at least once and the RDA has yielded a result, and “false” if the message was not received correctly in this message transmission interval.

Sender Status

If an ECU hosts several subsystems, and one (fail-safe) subsystem fails, the others still should be able to send their data. Turning off the entire ECU is thus not an option.

But as the communication controller works, it sends all messages, and potentially incorrect values for messages produced by the failed subsystem.

One classic strategy to handle this problem is to define an “invalid” value. This is unfavorable because it introduces a hidden information channel; if some application program fails to check for this special value in the right way, the system becomes inconsistent. Also, the “invalid” value might fall into the range of valid values after a software extension or upgrade. Any RDA function calculated in the FT-COM layer must take this into account.

The sender status of a message is part of the message itself, and therefore part of the input vector to the RDA function. The RDA will then consider a message that was correctly received, but has a sender status of “invalid,” to be non-present. Clearly, the FT-COM code performs better if the sender status is only considered for those messages actually having one, and no such code or if-statement exists for messages that have no sender status.

The receiver status of a message is generated at the receiver and is always avail-able. Therefore, it can always be used for checking the availability of a message. But it does not carry the same amount of information that the sender status delivers: This information is generated by the sender, exists only if the system design requires it and allows the sender to explicitlyinvalidatethe message contents while still send-ing the message; this can be necessary for a more complex node design where more than one subsystem is executed on the node.

The sender status implies additional effort for the sender, i.e., the FT-COM code generated for the sender. It must be updated, and additional bandwidth (even if only a single bit) is needed on the communication bus. Furthermore, the receiver must explicitly check this sender status, in addition to the receiver status that is always processed.

Message Timing

The message timing should not be done by the application software because, besides becoming unnecessarily complex, this could raise timing problems due to program-ming errors or faults during execution. Based on the separation of concerns, message timing should be handled by the FT-COM layer, which takes full responsibility and

Development Tools 471 can be reused across different applications. The FT-COM code generator needs to respect all these timing constraints and “schedule” its tasks so that all messages are processed in time.

Message Buffer Handling

A replicated subsystemF that sends a messagemmay also want to receive this message. This sounds trivial, but requires some effort when replication is used, be-cause in this case it is not correct to simply access the message in the local RAM.

Say N is a node where one of the replicas ofF is executed, and assume that another subsystemG, which also runs onN, usesmas input. Receiving a message from a replicated subsystem requires an RDA (this is valid even for the subsystem that sends this message). Therefore,mexists twice onN: One instance is the value which is sent byF, to be entered in the RDA at all receivers (includingN), the other one is the result of the RDA atN. Usually these will be equal, but if, for example,m is a sensor reading with an agreement function that computes the average, the local sensor may produce a slightly different result than the other redundant sensors in the system, and the valuem that is actually used by the receivers (includingG) is an average of allm_ithat were transmitted in the previous round.

It follows that several message buffers can be required for a message, depending on whether the message is replicated or not:

• Atransmit bufferfor the message instance that is sent to all the receivers; this buffer is required for any message

• Receive buffersfor each of themi

• Aresult bufferfor the result of the RDA; this buffer is only required for repli-cated messages

Each of these buffers has the size (i.e., RAM requirements) of the message itself.

A generated FT-COM may only provide all these buffers for messages where it is really needed, and save RAM if a message is not consumed byF or if the RDA function allows to directly use the sent value (e.g., “one-valid”).

Packing of Bit Messages

Due to the CPU architecture of a node, the C variables containing the message values often use more memory than their data representation requires. The most common representatives of such a message type are Boolean messages, which have a data content of one bit, but are usually stored in a byte or even anint, depending on the CPU architecture and compiler.

However, since transmission bandwidth is rather expensive, the available net data rate should be optimally utilized. For this purpose, a Boolean message should be packed into a single bit, because it wastes a lot of space if it requires 16 or more bits for transmission. Similarly, a message which can take only one of 20 different values should not require 8 bits of transmission capacity, because the data content fits into

472 Time-Triggered Communication

5 bits. Likewise, sensor data from an A/D unit that has a significant range of 10 bits does not need to be transmitted in a 16 bit word — but the packing algorithm needs to know which of the 16 bits are the 10 relevant ones.

At the receiver, the message needs to be expanded into a variable that is again easy to handle, like anint. The algorithm needs to be the exact inverse of the pack-ing one, but must take into account several architectural properties that may differ between sender and receiver — the most prominent of all being the byte order.

On the other hand, the effort to efficiently (in terms of computation and code size) pack bit messages must be minimized, and there are much more efficient ways to achieve this than to simply consider the transmission buffer (frame) a long bit field and store all messages sequentially in this bit field. This is even true for standard messages of a size of 1, 2 or 4 bytes, and proper alignment can result in considerable performance gains.

However, manually programming such packing and unpacking routines for each bit message, and changing them consistently if something changes in the system specification (like a 10-bit A/D result being upgraded to 12 bits), is highly error-prone. Therefore, a layer that provides packing at the sender and unpacking at the receiver needs to be configured or created automatically, and must be supported by proper tools.

An automatically generated FT-COM layer may be optimized so that it only contains code that is really necessary for this particular platform, and that as many branches as possible are eliminated from the final code.