trimis.ec.europa.eu · Table of Contents Document versions

ACROSS ARTEMIS Cross-Domain

Architecture

D2.2 Functional Specification of Middleware and System Components

Project Acronym ACROSS Grant Agreement Number

ARTEMIS-2009-1-100208

Document Version

v1.0 Date 30.09.2010 Deliverable No. D2.2

Contact Person Christian El Salloum Organisation TU Vienna

Phone +43 58801 18225 E-Mail [email protected]

Del.No.(D2.2) Version: 1.0 Confidentiality Level: PU

30.09.2010 ACROSS Page 2 of 127

Document versions

Version No. Date Change Author(s)

V0.2 1.7.2010 Updated OPT6 Christian El Salloum Roman Obermaisser

V0.3 14.7.2010 Updated OPT2, OPT3, OPT4, OPT5, OPT11, OPT12, OPT13,OPT14

Christian El Salloum

Armin Wasicek

Roman Obermaisser

Ingo Rohloff

Jia Huang

v0.4 2.9.2010 Incorporated updates from all partners Christian El Salloum

Armin Wasicek

Roman Obermaisser

Ingo Rohloff

Jia Huang

Marco Alessandretti

Knut Degen

v0.7 Incorporated feedback from the first review round

Manfred Pisecky

Christian El Salloum

Armin Wasicek

Roman Obermaisser

Ingo Rohloff

Jia Huang

Marco Alessandretti

Knut Degen

Andreas Fleck

v1.0 final check Christian El Salloum


30.09.2010 ACROSS Page 3 of 127

Table of Contents

Document versions ....................................................................................................................................... 2

1 About this Document ............................................................................................................................ 8

1.1 Role of the Deliverable .................................................................................................................. 8

1.2 Relationship to Other ACROSS Deliverables ................................................................................. 8

1.3 Structure of this document ........................................................................................................... 8

2 Service Specification ............................................................................................................................. 9

2.1 Interfaces of a Service ................................................................................................................... 9

2.2 Service Configuration .................................................................................................................... 9

3 OPT1: Secure Global Time Service [TU Vienna, TTT] .......................................................................... 10

3.1 Rationale and Covered Requirements ........................................................................................ 10

3.2 Syntax .......................................................................................................................................... 10

3.3 Protocol ....................................................................................................................................... 10

3.4 Dependency on Other Services ................................................................................................... 10

3.5 Description .................................................................................................................................. 11

3.6 Fault Assumptions and Behavior in Presence of Faults .............................................................. 11

3.7 Configuration interface (Interface to WP3) ................................................................................ 11

3.7.1 Service configuration .......................................................................................................... 11

3.7.2 Resource configuration ....................................................................................................... 11

4 OPT2: Transparent Gateway Service [TTT] ......................................................................................... 12


4.2 Syntax .......................................................................................................................................... 12

4.3 Protocol ....................................................................................................................................... 12


4.5 Description .................................................................................................................................. 12





5 OPT3: Secure Group Communication Service [TU Vienna] ................................................................. 15


5.2 Syntax .......................................................................................................................................... 16

5.3 Protocol ....................................................................................................................................... 17


30.09.2010 ACROSS Page 4 of 127


5.5 Description .................................................................................................................................. 17





6 OPT4: Secure Boot Service [TU Vienna] .............................................................................................. 20


6.2 Syntax .......................................................................................................................................... 20

6.3 Protocol ....................................................................................................................................... 21


6.5 Description .................................................................................................................................. 22





7 OPT5: Voting Service [fortiss] ............................................................................................................. 24


7.2 Syntax .......................................................................................................................................... 25

7.3 Protocol ....................................................................................................................................... 26


7.5 Description .................................................................................................................................. 26





8 OPT6: State Externalization Service [TU Vienna] ................................................................................ 28


8.2 Syntax .......................................................................................................................................... 29

8.3 Protocol ....................................................................................................................................... 29


8.5 Description .................................................................................................................................. 30





30.09.2010 ACROSS Page 5 of 127


9 OPT7: State Restoration Service [TU Vienna] ..................................................................................... 32


9.2 Syntax .......................................................................................................................................... 32

9.3 Protocol ....................................................................................................................................... 32


9.5 Description .................................................................................................................................. 33





10 OPT8: Operating System Services [SYSGO] ..................................................................................... 34


10.2 Syntax .......................................................................................................................................... 34

10.3 Protocol ....................................................................................................................................... 34


10.5 Description .................................................................................................................................. 34



11 OPT9: BEE Services [ED] .................................................................................................................. 42


11.2 Syntax .......................................................................................................................................... 42

11.3 Protocol ....................................................................................................................................... 67


11.5 Description .................................................................................................................................. 72



12 OPT10: Real-Time Tracing Service [LAUTERBACH] ......................................................................... 90


12.2 Syntax .......................................................................................................................................... 91

12.3 Protocol ....................................................................................................................................... 92


12.5 Description .................................................................................................................................. 93




30.09.2010 ACROSS Page 6 of 127

13 OPT11: Debugging Service [LAUTERBACH] ..................................................................................... 94


13.2 Syntax .......................................................................................................................................... 94

13.3 Protocol ....................................................................................................................................... 95


13.5 Description .................................................................................................................................. 96



14 OPT12: Health Monitoring Service (Local DU) [LAUTERBACH] ....................................................... 97


14.2 Syntax .......................................................................................................................................... 98

14.3 Protocol ....................................................................................................................................... 98


14.5 Description .................................................................................................................................. 99


14.7 Configuration interface (Interface to WP3) .............................................................................. 100

15 OPT13 Health Monitoring Service (Global DU) [LAUTERBACH] .................................................... 101

15.1 Rationale and Covered Requirements ...................................................................................... 101

15.2 Syntax ........................................................................................................................................ 101

15.3 Protocol ..................................................................................................................................... 102

15.4 Dependency on Other Services ................................................................................................. 102

15.5 Description ................................................................................................................................ 103

15.6 Fault Assumptions and Behavior in Presence of Faults ............................................................ 103


16 OPT14: Virtual CAN service [TU Vienna] ....................................................................................... 104


16.2 Syntax ........................................................................................................................................ 104

16.3 Protocol ..................................................................................................................................... 105


16.5 Description ................................................................................................................................ 105

16.5.1 Receive Queues (BasicCAN) .............................................................................................. 106

16.5.2 Message Buffers (FullCAN) ................................................................................................ 107

16.5.3 Data structures .................................................................................................................. 108

16.5.4 API Calls ............................................................................................................................. 108



30.09.2010 ACROSS Page 7 of 127


16.7.1 Service configuration ........................................................................................................ 111

16.7.2 Resource configuration ..................................................................................................... 112

17 OPT15: I/O Service [TTT] ............................................................................................................... 113


17.2 Syntax ........................................................................................................................................ 113

17.3 Protocol ..................................................................................................................................... 114


17.5 Description ................................................................................................................................ 114

17.5.1 Status values ..................................................................................................................... 115

17.5.2 Digital IO ............................................................................................................................ 116

17.5.3 Analog IO .......................................................................................................................... 116

17.5.4 PWM IO ............................................................................................................................ 116

17.5.5 Communication Control for TTP ....................................................................................... 117

17.5.6 Communication Control for TTEthernet ........................................................................... 118

17.5.7 Communication Control for Ethernet ............................................................................... 119

17.5.8 Data transfer for Ethernet ................................................................................................ 120





18 OPT16: Mass Storage Service ........................................................................................................ 122


18.2 Syntax ........................................................................................................................................ 122

18.3 Protocol ..................................................................................................................................... 123


18.5 Description ................................................................................................................................ 123





19 Annex: Additional Requirements to D2.1 ..................................................................................... 125


30.09.2010 ACROSS Page 8 of 127

1 About this Document

1.1 Role of the Deliverable

This document specifies the generic optional services of the ACROSS architecture.

1.2 Relationship to Other ACROSS Deliverables

The generic optional services are based on the core services specified in D1.2, and constitute a foundation for the domain specific services and the demonstrators in WP4, WP5 and WP6. In addition, this document specifies the interface to WP3 for the configuration of the generic optional services.

The specification of the BEE middleware is identical in D2.2 and D5.2. Since DDS is a standard and the interoperability is a main feature of the standard, the provision of the same identical APIs among different versions is a requirement. The implementation and design will differ between the two versions. The realization natively on the ACROSS core services will occur in WP2, while the realization on the domain-specific APEX will occur in the scope of WP5. It will differ in the set of underlying services they will rely upon, then the external required interface, and obviously the set of modules which implement them. Both of these items will be addressed in the product architecture (T2.3, T5.3).

1.3 Structure of this document

Section 2, gives an overview of service interfaces and service configuration. The following sections are concerned with the specification of the individual generic optional services.


30.09.2010 ACROSS Page 9 of 127

2 Service Specification

2.1 Interfaces of a Service

A service can have multiple interfaces via which it interacts with its user:

• It can interact with other components via messages exchanged over the TTNoC

• It can interact with an application or another service located on the same component via an API. The API can consist of a behavioral interface and an interface for reconfiguration.

Not every service must provide both kinds of interfaces (e.g., the global time service disseminates an agreed time value as a message over the TTNoC and has no API).

Service

behavior reconfiguration

Message interface

API

Figure 1: Relation between Services and applications

2.2 Service Configuration

The configuration of a service can be split into two parts: a service configuration providing configuration data for the service itself, and a resource configuration to allocate required resources. Resources consist on the one hand of resources available from the TTNoC like ports, and on the other hand of additional resources like memory requirements, CPU modes, or the configuration of the local interfaces.

Service

Resources

allocates

Service configuration

Resource configuration

Figure 2: Configuration split between services and resources

This document reflects these circumstances in the respective sections “Configuration interface to WP3”, by providing and interface for the model based design approach in order to instantiate and use the generic optional services of WP2.


30.09.2010 ACROSS Page 10 of 127

3 OPT1: Secure Global Time Service [TU Vienna, TTT]

3.1 Rationale and Covered Requirements

The secure global time service provides fault-tolerant external clock synchronization to enable the temporal coordination of activities performed by an SoC and its environment (e.g., other ACROSS SoCs or non-ACROSS components). The following requirements are covered by the secure global time service:

• R 2.1.1 (System-wide Global Time Base) • R 2.1.2 (Multiple Granularities) • R 2.1.3 (Consistent Ordering of Events) • R 2.1.4 (Common Time Format) • R 2.1.5 (Secure Clock Sync.)

3.2 Syntax

interface SecureGlobalTime { typedef unsigned long long omg_time_64; enum state { external_time_valid,

external_time_invalid, }; struct ExternalTime { omg_time_64 ExternalTime; state SynchronizationSate;

}

}

3.3 Protocol

As long as the external time is not synchronized (e.g, after startup, or before the MPSoC is connected to another device), the SynchronizationState will have the value external_time_invalid. After the external time synchronized with other devices in the off-chip network, this value will change to external_time_valid.

The period and the phase offset with which the external time value is disseminated are configurable parameters.

3.4 Dependency on Other Services

This service depends on the availability of a off-chip network with a global notion of time (e.g., TTP, or TTEthernet).


30.09.2010 ACROSS Page 11 of 127

3.5 Description

The global time service provides a system-wide global time base across multiple MPSoCs, thereby enabling the consistent temporal ordering of events according to a macroscopic time scale. The service is resilient against accidental faults (e.g., transient or permanent hardware faults) as well as malicious faults. With respect to malicious faults, the clock synchronization service tolerates many different types of attacks including fabricating, replaying or delaying of synchronization messages as well as violating their integrity by modification.

The service is realized as a system component, and shares the IP core with the gateway component of the corresponding time-triggered off-chip protocol (TTEthernet or TTP). The global time service disseminates periodically the agreed global time of the off-chip network to the NoC via a time-triggered state port. This message can be used by the core services of WP1 to adjust the internal time of the NoC.

3.6 Fault Assumptions and Behavior in Presence of Faults

The fault assumptions concerning the clock synchronization in off-chip networks can be directly derived from the employed communication protocol (see the appropriate specification documents for TTP, TTEthernet).

In ACROSS we extend the fault assumptions by malicious faults. The following attempts to modify the external time base will be reliably detected:

• Modification of clock synchronization messages

• Fabricating of clock synchronization messages

• Delaying of clock synchronization messages

• Replaying of clock synchronization messages

In each of these cases the SynchronizationState will be set to external_time_invalid.

3.7 Configuration interface (Interface to WP3)

3.7.1 Service configuration • PortID: The ID of the port through which the time value is sent

3.7.2 Resource configuration 3.7.2.1 Trusted Resource Manager

• The TTNoC Port has to be allocated

• The time message has to be routed to all components that require this


30.09.2010 ACROSS Page 12 of 127

4 OPT2: Transparent Gateway Service [TTT]


The transparent gateway service facilitates the dependable interconnection of multiple ACROSS MPSoCs via off-chip networks. Thereby, the transparent gateway service performs protocol conversion between on-chip and off-chip networks and supports transparent communication across multiple MPSoCs by abstracting from the underlying network technology.

To be able to integrate multiple SoCs with mixed criticality levels into a single system, the transparent gateway services will provide encapsulation mechanisms for containing faults in one SoC for preventing the propagation of faults to other subsystems.

• R 2.1.6 (Encapsulation) • R 2.1.8 (Timeliness for end-to-end communication) • R 2.1.9 (Support for Reliable Off-Chip Transport) • R 2.6.1 (Standard Communication Protocols)

4.2 Syntax

This service is transparent to the application cores. Applications will simply use the API of the core services for sporadic and state message transport. It is transparent whether the communication partner resides on the same MPSoC or not.

4.3 Protocol

As mentioned above, this service is transparent to the application.


Core services for sporadic and state message transport. The IO Service is needed for granting access to the off-chip networks (network control).

4.5 Description

The transparent gateway service enables the interconnection of multiple ACROSS MPSoCs via tunneling the NoC traffic through the off-chip network.

It offers the following features to the application:

• Support for uniform communication via heterogeneous networks • Abstract from the underlying communication technology • Resolve property mismatches • End-to-end timeliness guarantees across multiple chips • Reliable message transport • Temporal and spatial partitioning for logical channels • Support for phase alignment


30.09.2010 ACROSS Page 13 of 127

In order to provide the features mentioned above, we will employ time-triggered networks (e.g., TTP or TTEthernet) for the interconnection of multiple MPSoCs. A major challenge is phase alignment between the NoC and the off-chip network: Since the envisioned service is required to perform timely network activities in both networks, it has to align the different time formats in a consistent manner.

This is done in two steps:

1. Set up a consistent representation of time for both networks facilitating an intermediate time format (considering horizon and granularity of each time format)

2. Implement transfer functions to convert between the different time formats

3. Ensure the consistency of a signal even if both networks are not synchronized. In this case the end-to-end timeliness is not guaranteed.

Furthermore, the temporal alignment of time-triggered messages requires some scheduling efforts, off-line, during the system design phase. A consistent representation of time is a pre-condition for this. Additionally it requires synchronization during runtime to achieve and the preserve the synchronization between TTNoC and off-chip networks.

A common notion of time is established by external clock synchronization (OPT1).

Start of round

End of round

1. receive instant 2. forward instant

alignment

Figure 3: Phase alignment between time-triggered networks

Figure 3 shows the phase alignment between receiving and forwarding a time-triggered message at the gateway. The receive instant of a message must be aligned with the forward instant of the message within some reasonable bounds. Important factors of choosing the right alignment interval (phase offset) between those two instant are jitter, slot duration, and round duration. The time-triggered sending of messages is supported by the core services via the state message class.


Time-triggered/Time-triggered Transfers

• Synchronization failures (external time not available)

• Alignment of different network schedules not possible

These errors can be forwarded to the diagnostic component


30.09.2010 ACROSS Page 14 of 127


The configuration of the transparent gateway Service consists mainly of mapping ports of the TTNoC to messages in the off-chip network-

4.7.1 Service configuration • Mapping of TTNoC PortIDs to messages of the off-chip network (if multiple TTNoC ports are

mapped to a single message, the offset within the message has to be included)


• TTNoC Ports at the gateway have to be allocated

• Routing of messages from application components to the gateway ports

4.7.2.2 Additional resources

• General configuration of the off-chip network via the gateway’s communication controller

o E.g., TTEthernet or TTP MEDL, bandwidth, …


30.09.2010 ACROSS Page 15 of 127

5 OPT3: Secure Group Communication Service [TU Vienna]


Secure group communication protocols can divide the components of a system (e.g., ECU of a car) into two classes, one class that is allowed to access and participate in the system and one class that is rejected and consequently decoupled from the network. Many applications in the automotive, avionics, and industrial domains rely heavily on multicast or broadcast communication. As an example, consider a sensor value which is measured at given location within a vehicle and which is distributed to different nodes (e.g., the value of a sensor measuring the revolutions per minute of a wheel in a car is required for the ABS and the ESP systems). However, from a security viewpoint, it might not be desirable that (a) all potential receivers of a broadcast message actually can make use of the transported information, and that (b) every sender in a system is considered as trustworthy (see Figure 4). These circumstances are covered by the secure group communication service. The Secure Group Communication Service efficiently partitions the nodes in an insider and outsider group for each broadcast or multicast channel by cryptographic means. A specific challenge is to develop a strategy for the secure distribution of cryptographic keys with respect to their expiration dates.

Figure 4: Secure Group Communication Service partitioning nodes in inside and outside groups: (a) draw a border between

broadcast receivers, and (b) establish a relation of trust among inside group members

Time-triggered systems provide a global time base that enables the temporal coordination of activities executed in different parts of the system (e.g., the flaps on the right and left wing of an aeroplane have to be temporally aligned). In addition to the temporal coordination, a consistent notion of time can also be used to implement security mechanisms in a resource efficient way. For instance, in the presence of synchronized clocks, secure group communication protocols supporting broadcast authentication and non-repudiation can be realized with symmetric ciphers instead of costly public key digital signatures (#reference). There is a key difference for this service for on-chip and off-chip communication. For on-chip communication the core services of the TTNoC establish a reliable and secure multicast communication under supervision of the TNA. For off-chip communication, the case is not quite as clear. Cable connections and network switches are more susceptible to malicious attacks than channels within a chip


30.09.2010 ACROSS Page 16 of 127

package. Therefore, additional means have to be taken to secure off-chip communication like, for instance, cryptographic ciphers. These ciphers have to be embedded in some sort of secure communication protocol to ensure their safe and secure execution. The Secure Group Communication service implements a mechanism to exclude a given set of receivers from a multicast/broadcast channel and to guarantee the authenticity of information within a group. If information security is not the major concern of the group communication service, the services entry points to the TTNoC can be used for enforce other end-to-end mechanisms. For instance, end-to-end integrity checks can be generated and appended to a message by means of checksums replacing the computation of the cryptographic ciphers.

• R 2.1.7 (Secure Group Communication) • R 2.6.10 (Checksums for Communication)

5.2 Syntax

interface SecureGroupCommunication { typedef unsigned long pointer; typedef unsigned short opt3_error_code; typedef unsigned short authorization_request_type; typedef key_t octect[KEYLEN]; enum sgc_error_code_t { invalid_port_id,

invalid_config,

config_not_authorized,

config_not_registered,

port_lost, };

struct channelconfig { pointer checksumfunc,

key_t key, };

sgc_error_code_t sgc_receive_msg (in unsigned short PortID, out any Message, in octet blocking, in unsigned short ChannelConfigID) sgc_error_code_t sgc_send_msg (in unsigned short PortID, in any Message, in octet blocking, in unsigned short ChannelConfigID) sgc_error_code_t sgc_register_channelconfig(in unsigned short PortID, in pointer ChannelConfig, out unsigned short ChannelConfigID) sgc_error_code_t sgc_unregister_channelconfig(in unsigned short PortID, in unsigned short ChannelConfigID) };


30.09.2010 ACROSS Page 17 of 127

5.3 Protocol

The interaction protocol to the Secure Group Communication Service covers two interfaces, one for key management and one for secure data transmission. The key management is performed by a security kernel which is installed either locally within the scope of the core’s OS and governed by system calls or on a dedicated core of the MPSoC and directed by a message passing interface.

Before a secure data transfer can be started the channel has to be appropriately configured including the distribution of cryptographic keys (e.g., session keys). This part is facilitated by the sgc_register_channelconfig to associate a security configuration to a channel and respectively the sgc_unregister_channelconfig to disassociate the binding between configuration and channel. Each newly registered configuration must be authorized by the security kernel, before it can be used. A successful authorization returns a ChannelConfigID identifier which can be used by the sgc_send_msg and sgc_receive_msg services to transmit data according to the specified security configuration.


Core services for port configuration, send and receive operations

5.5 Description

The optional Secure Group Communication Service overwrites the respective send and receive core services. In addition, it provides functions for key management and key distribution. A security kernel which manages a core’s keys is executed either locally in a core’s the operating system or remotely on a dedicated core of the MPSoC. The special property of the security kernel is that it does not leak any information to the outside (except ids for registered configurations). Depending on the requested authorization type, the kernel performs various key authentication procedures, for example, key agreement with other kernels which can be located on-chip or off-chip.

Enables secure communication among multiple MPSoCs

• Device authentication The security kernel hosts various types of keys. A special key associated with the physical hardware (e.g., RSA key stored in a tamper proof memory, or a physically uncloneable function) can be used to implement a device authentication service on top of the Secure Group Communication Service.

• Multi-cast authentication:

The Secure Group Communication Service can be used to instantiate security protocols for multi-cast authentication.

• Confidentiality and integrity of messages Each channel can be associated with a particular configuration defining a security layer on top of the core services. This configuration can contain many different types of ciphers and security protocols, e.g., for confidentiality or integrity of information.


30.09.2010 ACROSS Page 18 of 127

• Key management and key distribution When registering a channel configuration for a particular port, the security kernel performs various tasks to enable the transparent usage of the Secure Group Communication Service. Examples for these tasks are remote key exchange, replacement of expiring keys, generation of session keys, automatic distribution of keys, and eventually dissemination of diagnostic information about security violations.

• Generate and verifies checksums for the purpose of reliable on-chip communication:

A channel configuration supports different ciphers and authentication schemes. The semantics of a secure channel can be used to register a checksum with some general parameter (e.g., a generator polynomial) as key. The mechanism then performs an end-to-end check of the integrity of a message.

The meaning of the error codes is as follows:

Error Code Meaning

invalid port_id The port is not configured in the TISS.

invalid_config The submitted configuration is formally invalid (e.g., NULL pointer, inaccessible memory area).

config_not_authorized The submitted configuration cannot be authorized by the security kernel.

config_not_registered The configuration used for the send or receive operation is not registered by the security kernel.

invalid_auth The received message cannot be authenticated.

port_lost The port is no longer available (e.g., removed in a new mode of the TTNoC).


As an exemplary attacker model, we assume an attacker who is able to access the communication system in a way to inject valid messages at any given instant to the channel. It can thereby overwrite messages which are in transit (e.g., currently stored in a switch’s output queue or in the memory of a receiver’s network adapter). Furthermore, it can make use of a clock which is synchronized to the global time of the network. Under the assumption of the attacker model as described above, we introduce two attacks with respect to the message authenticity and channel integrity:

1) Insertion attack: A new message is injected in an event-based message channel producing a faked event.

2) Substitution attack: A state message is replaced by a malicious message inducing a view on the environment which must not correspond to reality.


30.09.2010 ACROSS Page 19 of 127

Both attacks are instances of masquerading failures which occur if an erroneous node assumes the identity of another node and causes harm to the system. The original definition describes a masquerading failure as accidental bit flips in the destination field of a message. Opposed to that definition, in the presented attacks this modification is due to a malicious interaction fault. If the receiver of a message has no further knowledge about the sender’s identity, it must trust in the communication system to deliver authentic messages. A successful attack results in a corrupt system state, which can be one of the following:

• obvious: the system can detect the attack • unrecognized: the system continues to operation with malicious data • dormant: the attacker is under control, but does not yet take an action to modify the system

A successful attack does not only threaten the authenticity of single messages, but also violates the overall integrity of the communication channel.


The configuration of the Secure Group Communication Service encompasses the assignment of security configurations to ports on the TTNoC, hence adding certain security properties to the associated channel on the TTNoC. In addition with, e.g., the transparent gateway service, these security properties should hold also for the transmission over an untrusted off-chip network.

5.7.1 Service configuration • Assignment of a particular security configuration to a channel. The channel security

configuration should indicate the used ciphers, modes, keys, and other relevant data for the correct execution of the used security protocols.


• TTNoC Ports at the sending and receiving components have to be allocated

• Routing of messages between these ports has to be established


• General configuration of the components executing the security kernel

o e.g., enables MMU to provide memory protection.


30.09.2010 ACROSS Page 20 of 127

6 OPT4: Secure Boot Service [TU Vienna]


To avoid the execution of software damaged or modified during storage, job images must be checked for their integrity prior to execution.

The goal of the Secure Boot Service is to verify the binary job image of an application before it is started. Many types of Malware (viruses, worms, Trojans, etc.) aim at modifying the applications original code in order to insert a malicious routine. This kind of attack targets the integrity of a system and it can be recognized given an integrity checksum computed by a cryptographic hash algorithm (e.g., SHA1, MD5) and an appropriate authentication scheme. This scheme is most likely built using asymmetric ciphers (digital signatures), but is not limited to them and could as well be implemented using symmetric ciphers (Message Authentication Codes). Of course, both approaches have different advantages and drawbacks.

In addition, each job image carries a unique identifier which can be used to create a binding between the software and the hardware. This is often mandatory for certification concerns, where certain versions of a job image are certified to a particular hardware.

Relevant requirements are:

• R 2.2.3 (Secure Boot)

• R 2.6.9 (Configuration Reporting)

6.2 Syntax

interface SecureBootService { enum sbs_error_code_t { invalid_job_id,

job_does_not_exist,

job_invalid, job_not_authenticated,

job_not_authorized,

invalid_permissions,

}; struct job_id_t { int id, }; struct permissions_t { int perm, }; sbs_error_code_t sbc_start( in job_id_t job, in permissions_t req_perm );

sbs_error_code_t sbc_verify( in job_id_t job );


30.09.2010 ACROSS Page 21 of 127

sbs_error_code_t sbc_authorize( in job_id_t job, in permissions_t req_perm );

};

6.3 Protocol

The Secure Boot Service follows a five step procedure to transfer, load, and execute job images. Figure 5 depicts the whole procedure, a textual description follows:

Authority

Host @ ACROSS MPSoCHost processor

Job image

Checksum

2. sign

3. verify

4. authorize

5. start

Job image

1a. deliveroperator

Authentication key 1b. deliver Verification key

011001010001111010010101111010111001101011110111010101011011000101001110101101110011100012

011001010001111010010101111010111001101011110111010101011011000101001110101101110011100012

Figure 5: Execution of Secure Boot Service

1. The application binary is delivered in step 1a to the operator of an ACROSS MPSoC by a vendor or a software development team. The operator stores the job image in the respective persistent storage location of the ACROSS MPSoC (e.g., a flash memory).

2. The operator incarnates the authority responsible for deciding which applications can safely be executed on the target ACROSS MPSoC. If the authority’s tests on the job (e.g., virus check) show that it is secure, and if it origins from a trusted source (i.e., the trusted creator), the authority will append a digital signature to the job image in order to allow the detection of future modification or substitution. The checksum is generated either by a private/public key pair (Authentication key differs from Verification key) or by a symmetric cipher (Authentication key equals Verification key). After successfully signing the job image, the operator transmits the job image plus its checksum to the target host, where it is stored in an appropriate location.

3. After a power up or reset of the ACROSS MPSoC, the host invokes the basic boot service (core service). It fetches the job image either from a local storage (e.g., a flash memory) or from a remote location (e.g., another host). Before it transfers control over the processor to the job, it calls the Secure Boot Service in order to check the job image for integrity and authenticity. This guarantees that only authorized software is executed on the target host.

4. If the verification step finishes successfully, the Secure Boot Service authorizes the host to execute the job on its processor.


30.09.2010 ACROSS Page 22 of 127

5. Finally, the host loads the job image in its working memory and executes the job.


This service depends on the core communication services, the basic boot service, the gateway services, and optionally the operating system services.

6.5 Description

The Secure Boot Service extends the Basic Boot Service by a verifying the integrity and authenticity of a job image when it is loaded into the system. Each job image is assigned an external unique identifier by an external authority. It offers following features:

• Supports dynamic loading job images via the Basic Boot Service • Provides a cryptographically verifiable unique identifier for each loaded application image • Empowers the host to maintain an Access Control List (ACL) to implement access controls • Optionally, the Secure Boot Service may be integrated in the OS services

sbc_start: Description: Checks and starts a job on a single host. In the first stage, the Basic Boot Service is

used to load the job image and the checksum to the host’s memory. In the second stage, the Secure Boot Service verifies and authorizes the job image to execute in the host. Each host can maintain an ACL to grant or deny access to its processor for a job.

Parameter: job (in) Unique job identifier

req_perm (in) Requested permissions Return Value: secure boot error code sbc_verify: Description: Facilitates the verification of the job image. It runs a cryptographic cipher to check the

authenticity and the integrity of a job image. Parameter: job (in) Unique job identifier Return Value: secure boot error code sbc_authorize: Description: Checks if a job is eligible to execute on a host’s processor according to some ACL. The

definition of the ACL may be maintained by some software external to the Secure Boot Service, e.g., an Operating System.

Parameter: job (in) Unique job identifier

req_perm (in) Requested permissions Return Value: secure boot error code

Error Code Meaning

invalid_job_id The job id does not exist or the format is invalid.


30.09.2010 ACROSS Page 23 of 127

job_does_not_exist The job image belonging to that id does not exist.

job_invalid The integrity check on the job image failed.

job_not_authenticated, The authenticity check on the job image failed.

job_not_authorized The authorization check on the job id failed.

invalid_permissions The permission format is invalid.


The assumed intentional faults are:

• Job image is fake

• Job image has been corrupted

• Job image has been replaced


The configuration of the Secure Boot Service encompasses the definition of a cipher and a key in order to decrypt/authenticate a given job image.

6.7.1 Service configuration • Definition how the secure boot service should check a binary job image. This can be a cipher and

a key.


• TTNoC Ports in order to load an image from a storage


• Deployment of required cryptographic functions at the instantiating components

• Protection of local cryptographic processing tasks

• If key certificates are used, decoding functions to load the keys into memory

• If the job images are signed externally, an intermediary to negotiate the trust relationships between signer and component (e.g., a Certification Authority).


30.09.2010 ACROSS Page 24 of 127

7 OPT5: Voting Service [fortiss]


Multiple application domains of ACROSS involves safety-critical applications. To develop such applications on a complex platform like the ACROSS MPSoC, the design must not rely on 100% correctness for devices and interconnects. Particularly for safety-critical systems, transient/permanent faults may lead to catastrophic consequences. Hence, the ACROSS architecture and methodology framework must enable efficient construction of fault-tolerant systems. For this reason, this work package should provide a flexible voting service, which is a commonly used fault-tolerant mechanism. The basic idea of voting services is to actively replicate multiple copies of a safety-critical component, such that faults from minority of components can be masked by the correct results from the majority of the components.

Figure 6.1: An example TMR system One commonly used setup of voting service is Triple Modular Redundancy (TMR), in which three nodes perform the same task and the results are processed by a voter to produce a single output. If any one of the three systems fails, the other two systems can correct and mask the fault. If the voter fails then the complete system will fail. However, in a good TMR system the voter is much more reliable than the other TMR components. Replication of the voter itself can also be considered for further improvement as well as the use of incoming voting. Figure 6.1 shows and example scenario where a safety-critical controller component is implemented as TMR. The sensing and computation is done on each node and the results are sent to the voter. Single node failure or message loss in the network can be tolerated. Since the sensor data may have intrinsic noise, a threshold is chosen to determine the equality of two values sent to the voter. For fault isolation reasons, it is preferable to implement the redundant components (voting nodes) in separate IP cores. The voter component can be implemented either in a separate processor or in the same processor as the application that uses the voted data. The later implementation is also known as incoming voting. In the case of incoming voting, the receiving application receives all redundant inputs and performs the voting itself using the underlying middleware service. An important issue for the

http://en.wikipedia.org/wiki/Reliability_engineering�


30.09.2010 ACROSS Page 25 of 127

voting service is that it should be transparent to the application code. The voter output is seen as a normal input port from the application side. The covered requirement is R 2.2.4 (Active Redundancy).

7.2 Syntax

interface voting { typedef UINT64 OMG_TIME_64 typedef UINT32 pointer enum voting error_code { invalid_variable_id, invalid port_id, invalid_pointer, invalid_updatephase, invalid_msgoffset, invalid_variablesize, invalid_variabletype, invalid_period, failure_node }; voting_error_code RegisterVotingNode (in UINT32 VariableID, in UINT32 VariableSize, in data_type VariableType, in UINT16 PortID, in UINT32 MsgOffset) voting_error_code RegisterVoterInput (in UINT8 VotingID, in UINT8 NodeID, in UINT8 Priority, in UINT32 VariableID, in UINT32 VariableSize, in data_type VariableType, in UINT16 PortID, in UINT32 MsgOffset) voting_error_code SetVoterOutput (in OMG_TIME_64 UpdatePeriod, in OMG_TIME_64 UpdatePhase, in pointer VariablePointer) voting_error_code CreateVoting(out UINT8 VotingID) voting_error_code DeleteVoting(out UINT8 VotingID) voting_error_code EnableVoting(in UINT8 VotingID) voting_error_code DisableVoting(in UINT8 VotingID) voting_error_code SetMaxDelta (in UINT8 VotingID, in UINT8 NodeID, in pointer MaxDelta) voting_error_code SetVotingAlgorithm(in UINT8 VotingID, in pointer Algorithm) //depending on diagnostic services voting_error_code SetHealthMonitoringPort(in UINT8 VotingID, in pointer HealthMonitoringPort) voting_error_code EnableErrorReport (in UINT8 VotingID)


30.09.2010 ACROSS Page 26 of 127

voting_erro_code ErrorReport(in UINT8 VotingID, in UINT8 NodeID, in voting_error_code error_code) };

7.3 Protocol

To build a voting system, registration needs to be done on each node and the voter. At the node side, RegisterVotingNode should be called to register a variable that should be sent to the voter.

At the voter side, the following procedure should be done before enabling the voting service:

• Create the voting and obtain voting ID using CreateVoting

• Register all input variables and the output variable

• Set the voting algorithm

• Set the error reporting to health monitoring system (optional)

• Enable the voting

The voting services are transparent to the applications. The safety-critical variable used by the application will be automatically updated by the voter at the specified time.

Optionally, the voting service and report failure of the node/voter to health monitoring subsystem. For that the health monitoring port should be registered correspondingly.


This service depends on the core communication services and the core clock synchronization services.

7.5 Description

RegisterVotingNode is used by the voting node to register a variable that should be sent to the voter. The variable labeled by the VariableID will be sent using the port labeled by PortID at the message location identified by MsgOffset.

CreateVoting is called at the processor that executes the voting service. It returns a unique VotingID. DeleteVoting removes an existing voting service.

EnableVoting and DisableVoting is used to start and stop the voting service, respectively.

RegisterVoterInput is be used by the voter to subscribe an input for the voting system. The input is identified by the NodeID. The input is obtained from the port labeled PortID at the message location identified by MsgOffset. The VariableType is necessary for the voter to correctly interpret the value.

SetVoterOutput is used by the voter to set the output variable. The voting result will be written periodically to variable pointed by VariablePointer at time specified using UpdatePeriod and UpdatePhase.

Since the input values, especially for analog inputs, may suffer from noise, SetMaxDelta is used to set the maximum reasonable deviation between the real value and the input value. The Delta is used by the voting algorithm is decide if an input is fault state.

SetVotingAlgorithm is used to specify the voting algorithm. The function pointed by Algorithm will be used to compute the voting result. Some widely used strategies will be provides as a library.


30.09.2010 ACROSS Page 27 of 127

SetHealthMonitoringPort is used to specify the port for error reporting. In this case, failure of the voting nodes can be reported to the health monitoring subsystem for recovery. Error reporting service is enabled using EnableErrorReport.


Transient faults e.g. loss of the message containing the voting input can be masked by correctness of majority of voting nodes. Failure of minority of voting nodes can be identified by the voter and reported to the health monitoring port. In case no active replication of the voter is available, failure of the single voter component will lead to the failure of voting service.


7.7.1 Service configuration • Input Configuration

o PortID

o DataType

o Priority

o Variable

o MaxDelta

• Voter Configuration

o VotingID

o Voting Output

o OutputUpdatePeriod

o OutputUpdatePhase

o Voting Algorithm

o HealthMonitoringPort

7.7.2 Resource configuration 7.7.2.1 Trusted Resource Manager TTNoC Ports and channels to and from the voter


30.09.2010 ACROSS Page 28 of 127

8 OPT6: State Externalization Service [TU Vienna]


For various reasons, such as state validity checking, state exchange, logging purposes, and global state snapshot, components should be able to easily externalize their state. State externalization is very important for the fast recovery of platforms/components affected by transient faults. The externalised information can be used to 1) allow error detection and/or 2) enable checkpointing and retry mechanisms (e.g., depending on the inertia of the controlled process, a component could restart with the state of the previous period, after a transient fault has occurred). In the case of state recovery based on checkpointing and roll-back, the choice of state externalization frequency should make a good compromise between the communication/computational overhead related to the state externalisation itself and the extent of roll-back in the case of an error.

This service supports time triggered externalization of component states. Through this service, an application can register a data object (a simple variable or a complex structure) which is then periodically disseminated by the state externalization service and packed (together with other registered data objects) into a message and sent over a dedicated channel.

Figure 8-1. A component’s state cycle. 1) The component is in a ground state and the externalization service acquires the image of the state. 2) A message with the state is sent. 3) A message with restart state is possibly received and the component restores its state during the interval (3, 1).

Figure 8-1 depicts the schematic picture of a state cycle of a component which was designed so that it periodically enters a ground sate. The periodic state externalization service acquires the component’s state at instant 1 when the component is in its ground state. The state is packed into a message and transmitted at instant 2. The state externalization message is processed by the rest of the system during the interval (2, 3). In case that a diagnostic component detected an error in the ground state, it issues a restart message containing a correct state. This restart message is received at instant 3 and the component restores its state during the interval (3, 1). In this setup, the monitoring component is mission-critical and it should be a trusted component.

The externalization message might contain the timestamp when the state was acquired, that is, the receiver of the message must be able to deduce the duration of the (1, 2) interval. In a time-triggered architecture such a timestamp is not required. If, for some reason, the externalization message cannot be updated, a "message age counter" might be used to deduce the freshness of the data.


30.09.2010 ACROSS Page 29 of 127

The covered requirement is R 2.2.1 (State Externalization).

8.2 Syntax

interface StateExternalization { typedef unsigned long pointer; typedef unsigned long long omg_time_64; typedef unsigned short error_code;

enum error_code { invalid_variable_id,

invalid port_id,

invalid_pointer,

invalid_updatephase,

invalid_msgoffset, invalid_variablesize,

invalid_period,

};

error_code RegisterVariable (in long VariableID, in unsigned long VariableSize, in unsigned short PortID, in unsigned long MsgOffset)

error_code Configure_Autonomous_Update (in long VariableID, in omg_time_64 UpdatePeriod, in OMG_TIME_64 UpdatePhase, in pointer VariablePointer)

error_code Perform_Update(in long VariableID, in pointer VariablePointer)

};

8.3 Protocol

RegisterVariable must be executed with a specific VariableID before an invocation of Configure_Autonomous_Update or Perform_Update is possible with that variable ID.

Perform_Update may only be invoked once within the period of the port, which is used for the externalization. The invocation of Perform_Update must be phase-aligned with the transmission of the associated message according to the time-triggered communication schedule.




30.09.2010 ACROSS Page 30 of 127

8.5 Description

RegisterVariable registers a variable to be externalized. The variable is named with an identifier VariableID. The parameter VariableSize denotes the size of the variable in bytes. The variable is externalized using the port with the identifier PortID. The MsgOffset is used to specify the starting position of the variable in the externalized message of the port with the identifier PortID.

Configure_Autonomous_Update is used for the autonomous externalization of the variable with the identifier VariableID with a specific period and phase of the global time base. The period and update are specified by the OMG time format. The synchronization between the generic optional service “state externalization” and the application code is performed implicitly using time. The offset and period of the externalization (i.e., UpdatePeriod and UpdateOffset) have to be aligned with the offset and period of the port and the updating of the variable by the application.

Perform_Update copies the variable identified by VariableID into the port, thereby offering the means for the application to provide a new value of an externalized state variable. VariablePointer defines the source address for the copy operation. The invocation of the call needs to be temporally aligned with the offset and period of the port.

The meaning of the error codes is as follows:

Error Code Meaning

invalid_variable_id The variable ID is unknown.


invalid_pointer The pointer is invalid (e.g., NULL pointer, inaccessible memory area).

invalid_updatephase The update phase is incorrect (e.g., larger than period).

invalid_msgoffset The message offset is incorrect (e.g., larger than the memory at the port).

invalid_variablesize The variable size exceeds the reserved memory at the port.

invalid_period The period exceeds limitations or architectural constraints of permitted message periods.

port_lost The port is no longer available (e.g., removed in a new mode of the TTNoC).


Synchronization failures (i.e., concurrent writing of a variable and communication at the TTNoC) are reported using the health monitoring port.


30.09.2010 ACROSS Page 31 of 127

A reconfiguration of the TTNoC has occurred and the port for externalizing the state is not available anymore. In this case, the application is informed using the respective error code (“port_lost”) and the incident is reported using the health monitoring port.


The configuration of the state externalization service identifies variables that should be externalized and maps these variables to ports of the TTNoC.

8.7.1 Service configuration • Variables that should be externalized

o Memory location

o Size

• Mapping of variables that should be externalized to ports


• TTNoC Ports to disseminate the state


30.09.2010 ACROSS Page 32 of 127

9 OPT7: State Restoration Service [TU Vienna]


The state restoration service covers requirement R2.2.2, and constitutes the counterpart of the state externalization service (OPT6). An overview of state recovery by using the services OPT6 and OPT7 is described in Section 8.1. The basic idea is that the state restoration service listens on a defined port, for a restart message (e.g., sent by the diagnostic unit). When a restart message arrives at a component, the component sets its state to the state contained in the restart message.

9.2 Syntax

interface StateRestoration { typedef unsigned long pointer; typedef unsigned short error_code; typedef unsigned long long omg_time_64;

enum error_code {

invalid port_id,

invalid_pointer,

};

error_code RegisterCallback (in pointer CallbackFunction, in unsigned short PortID)

void UnregisterCallback ();

//Callbackfunction implemented by the application void RestoreState (in pointer state, omg_time_64 timestamp)

};

9.3 Protocol

The service is operational after the RegisterCallback function has been called, and terminates after the function UnregisterCallback is called.


This service is closely related to the state externalization service (OPT6)


30.09.2010 ACROSS Page 33 of 127

9.5 Description

RegisterCallback is used to activate the state restoration service. It binds the service to the port PortID and registers the application-defined CallbackFunction that is used to restore the component’s state.

UnregisterCallback is used to deactivate the state restoration service.

The function RestoreState is defined by the user, and is called by the state restoration service whenever a restart message arrives. The parameter state is pointer to the user-defined data structure containing the state, and the parameter timestamp contains the time when the snapshot of the state was taken.

Error Code Meaning


invalid_pointer The pointer is invalid (e.g., NULL pointer, inaccessible memory area).


Since the state restoration service resides within the same fault containment region as the application, it might happen that both, the application and the state restoration service case to work. Such failures should be recovered by the watchdog service of the TISS.


The configuration of the state restoration service consists of the port via which the restart message is received and the restoration function that should be called upon reception.

9.7.1 Service configuration • PortID of the port of the restart message

• Function to be called upon restart


• TTNoC Port for restart message


30.09.2010 ACROSS Page 34 of 127

10 OPT8: Operating System Services [SYSGO]


• R 2.4.1 (Operating System Services API)

• R 2.4.2 (Thread (Hard) Real-time Scheduling Mechanisms)

• R 2.4.3 (Thread Priority Inversion Prevention)

• R 2.6.2 (Execution of Precompiled Code)

• R 2.6.3 (OS Support for IP Protection)

• R 2.6.7 (Legacy device drivers)

All covered by OS

10.2 Syntax

• Described in detail in product documentation and reference manuals

10.3 Protocol

n/a


See OS requirements to hardware (CPU, RAM etc.)

10.5 Description

PikeOS is a platform for developing embedded systems where multiple operating systems and applications can run simultaneously in a secure environment. The PikeOS architecture is based on a microkernel design with a small, compact microkernel providing a core set of services.

The ACROSS project will start with v3.1 of PikeOS. It will run on the high-end internal CPU (NIOS) and the external CPU (ARM). Within the project the POSIX and ARINC-653 APIs will be used, optionally AUTOSAR and Linux will be available, too.

This paragraph is supposed to describe the fundamental concepts of the operating systems. As a baseline for the functional specifications (e.g. system calls, function arguments and return values) the appropriate reference manuals shall be used.

1.5.1 Overview


30.09.2010 ACROSS Page 35 of 127

Key terms within PikeOS are “task” and “thread”, The PikeOS interpretation of both terms is as follows:

• A thread is a piece of executable code which has access to data and stack. It is the basic PikeOS scheduling entity. Each thread is associated with a time partition, a task and the task’s resource partition.

• A task describes a separate address space, shared by all threads assigned to this task.

The PikeOS kernel offers preemptive multitasking, implementing priority based scheduling and supporting time and resource management.

The PikeOS System Software (PSSW), built on top of the microkernel, provides many of the services traditionally found inside a monolithic kernel, like starting applications or offering file access. Less common, the PSSW implements partitions, which are the secure environments applications run in. User applications, in a PikeOS system, can be anything from native PikeOS applications up to fully featured OS "personalities", which provide a complete emulation of an existing OS environment. Figure 1 illustrates the PikeOS architecture.

Figure 1: PikeOS architecture

1.5.2 PikeOS System Software (PSSW)

The architecture of the PSSW component is shown in figure 2. The ovals in the PSSW list the basic building blocks and services offered. The PSSW starts by establishing the system configuration, retrieving parameters for all other PSSW services from the Virtual Machine Initialization Table (VMIT). The VMIT is part of the ROM File System and is loaded by the PSSW module at boot time. The content of the VMIT is described in detail in PikeOS System Software Reference Manual, section 2, page 153.

Errors occurring during this system state are reported to the health monitoring subsystem of the PSSW which may either — depending on the specific error and the VMIT configuration — halt or reboot the target.


30.09.2010 ACROSS Page 36 of 127

Figure 2: The PikeOS System Software Architecture

After successful configuration, individual partitions are established by assigning resources and starting a partition daemon thread, later on interacting with the PSSW library much in the way the kernel in a monolithic system design does. This thread is already running with the properties defined in the VMIT respecting priorities and time partitioning. Errors occurring from now on are per default configured to affect the actual partition only.

Finally all application processes are loaded and started, if requested to.

Applications take advantage of PSSW services by means of the PSSW library. It is linked to the user application and hides the PikeOS kernel IPC protocol used to communicate with the PSSW Module from the user application.


30.09.2010 ACROSS Page 37 of 127

In general PSSW handles the following components:

(a) Resource Partitions

A Resource Partition can be seen as a container for user applications, with a statically defined set of resources and privileges. Resource partitions are created by the PSSW Module based on the configuration data in the VMIT. The configuration of a resource partition cannot be modified during system runtime.

(b) Application Process Management

User applications started by the PSSW Module are called processes. From the kernel point of view, these are simply PikeOS tasks. The PSSW adds semantics by assigning properties to these tasks. Processes access PSSW services by means of the PSSW library.

Processes are managed by the associated partition daemon in the PSSW Module, running in the time partition specified in the VMIT and at the PikeOS priority corresponding to the resource partition’s maximum priority. There is one partition daemon for each resource partition.

(c) Partition Communication Ports

PikeOS provides message based communication through statically configured communication channels. A communication channel is a link between two partition communication ports (PCPs), a source PCP and a destination PCP. The data flow is from the source PCP to the destination PCP. The source and destination PCPs may be located within the same partition, within two different partitions, or within one partition and a system extension.

(d) File System

The PikeOS File System offers a uniform way to access various types of files. The PSSW Module contains of a compact, generic file system layer that dispatches calls to the file providers. File providers are responsible for the actual characteristics of the files and the file operations. File access permissions are assigned on a per partition basis in the VMIT, but may be further constrained by a file provider.

(e) File Providers

The PSSW distinguishes between internal and external file providers:

• Internal file providers are an intrinsic feature of the PSSW and thus are instantly available as soon as the system starts up. This is especially important for the ROM File System which provides all files required for booting, such as the VMIT and the application binaries.

• External file providers are ordinary applications running in a partition. However, a special entry in the VMIT marks that an application in a partition will register as a file provider. In case of successful registration, the file system offered by this provider can be accessed transparently by other applications using the file system API. This is how devices, which have to be shared between partitions, are implemented.

(f) Shared Memory Objects


30.09.2010 ACROSS Page 38 of 127

PikeOS provides named shared memory objects which can be accessed by multiple resource partitions. The properties of a shared memory object are specified in the VMIT. All shared memory objects are created by the PSSW Module at boot time. During runtime, a shared memory object always exists, it is never deleted. An error that occurs during creation of the shared memory objects is reported to the PSSW health monitoring subsytem which will react according to the health monitor configuration of the VMIT.

(g) Time Partitioning

The PikeOS Time Partitioning ensures that the activities in one time partition do not affect the timing of the activities in other time partitions. PikeOS maintains a major time frame of fixed duration, which is periodically repeated throughout the runtime operation. Time partitions are activated by allocating one or more time-slots within the major time frame.

(h) Health Monitoring

The PikeOS health monitoring system is designed to handle errors at system runtime and to execute recovery actions as configured by the system integrator. It is mainly inspired by the ARINC 653 standard. Although health monitoring is implemented in the PSSW, the system integrator may also specify that certain error conditions are handled by application error callback functions.

1.5.3 PikeOS Kernel

The PikeOS microkernel itself handles the four basic entities (resource partitions, time partitions, tasks, and threads) in terms of communication, scheduling, exception management, and memory model.

(a) Communication

Inter Process Communication (IPC) is the primary thread communication mechanism in PikeOS. IPC message transfer can operate between threads in the same or different tasks but the kernel controls the scope of IPC by determining, in each instance, whether the two threads are permitted to communicate with each other. IPC transfer is synchronous and unbuffered, which requires an agreement between the sender and receiver of an IPC message. If either the sending or the receiving thread is not ready for message transfer, then the other partner must wait. Both threads can specify a timeout for the maximum time they are prepared to wait.

(b) Events

Event communication is the only service for asynchronous thread communication provided by the PikeOS kernel. Event communication is also the fastest communication service provided by the PikeOS kernel.

(c) Timeouts

The PikeOS kernel provides a logical timebase for system time and timeouts. The system time value represents the elapsed time since startup. The resolution of the system time is platform and configuration dependent.

(d) Scheduling


30.09.2010 ACROSS Page 39 of 127

PikeOS supports multiple concurrent threads and the PikeOS scheduler determines the order in which threads execute. The scheduler is activated whenever an event occurs that alters the state of the thread to be executed next.

The strategy implemented by the scheduler is a prioritized FIFO dispatcher. Whenever a thread becomes runnable, it is placed at the end of a ready list of threads runnable at that priority level. There is one ready list for each priority level supported by the kernel. When selecting the next thread to run, the scheduler always selects the first thread from the highest priority non-empty ready list. The currently running thread is called the current thread.

(e) User mode context

The user mode context is used by the PikeOS kernel to store the execution state of a thread whenever an exception occurs. It contains the processor’s general purpose registers, status registers, and if applicable on the platform and enabled in the context, vector and FPU registers and FPU status.

(f) FPU Support

The ability to use the FPU is controlled on a per thread basis. The PikeOS kernel manages the permission to use the FPU in a thread’s user mode context. If the user mode context enables FPU usage, the FPU state (i.e. FPU registers and state information) will be saved and restored on each context switch to and from that user mode context. The FPU state is embedded in the user mode context data structure.

(g) Vector Unit Support

The ability to use a CPU’s vector unit (if available) is also controlled on a per thread basis. Like the FPU, the PikeOS kernel manages the permission to use the vector unit in a thread’s user mode context.

(h) Exception Handling

Whenever the hardware detects an exception during execution of user code, the PikeOS kernel is entered. Some exceptions are handled directly by the kernel and therefore are invisible to the user code. Examples of exception types directly handled by the kernel are hardware interrupt handling, reloading of MMU or TLB entries as a result to MMU or TLB misses, system call dispatching or handling of trace and breakpoint exceptions used for debugging purposes.

(i) Memory Management

In PikeOS, all user code operates on virtual addresses which are translated by the MMU (Memory Man- agement Unit) of the CPU into physical addresses. On every memory access (read, write, or execute), the MMU also checks if the user task has the necessary access permissions for the memory location. If the user task attempts to access a virtual address for which the MMU does not find a valid translation, or for which the user task does not have the appropriate access permissions, a pagefault exception will be generated by the MMU.

(j) PSP Access

The PikeOS kernel is layered on top of an architecture dependent layer (called the Architecture Support Package, or ASP) and a platform dependent layer (called the Platform Support Package, or PSP).


30.09.2010 ACROSS Page 40 of 127

The ASP is an integral part of the kernel and provides a processor architecture abstraction layer for the PikeOS operating system. The ASP implements processor context management, exception management, address space and memory management, and debugger support.

The PSP contains all hardware platform dependent functions required by the operating system. The PSP typically implements system initialization, startup and shutdown, cache handling, serial I/O for diag- nostics and debug purposes (usually polled), hardware interrupt handling, and system clock (tick timer) handling.

(k) Initialization

Initialization of PikeOS and booting in general depends on the architecture and platform used. Typically, a ROM image is built before booting. The image contains all major parts of a PikeOS system:

• Platform Support Package (PSP) linked with the kernel, typically placed at the beginning of the image,

• a taglist containing user-configurable kernel and PSP parameters,

• the root task, and

• other files.

All items except the last are mandatory to bring up the system. The image itself may be encapsulated in a format readable by the bootloader, for example in an ELF image, S-Records or Intel HEX records. A special mechanism to boot the system over the NoC will be developed during the ACROSS project

1.5.4 I/O

The PikeOS System Software provides the possibility to define access rights to I/O resources on a per process basis. On process start, the configured I/O memory resources are mapped into the virtual address space of the process and can be directly manipulated by the application’s code. This a good starting point for small embedded applications or rapid prototyping.

Other designs may require hardware access to be concentrated in a library or in dedicated partitions running trusted code. In this way, large applications can run in separate partitions with no hardware access, thus enhancing the security and robustness of the system. Application I/O operations are delegated to the applications running in the trusted partitions. These processes performing the actual hardware access are called I/O servers.

The connection between the application and the I/O server is handled via PikeOS’ file system interface and therefore I/O servers are implemented as file providers. Typical I/O servers handle shared Ethernet, Serial Line or CANbus connections.

1.5.5 APEX (ARINC-653) Personality

The ARINC specification 653 published by Aeronautical Radio, Inc. (ARINC) specifies the baseline operational environment for application software used in Integrated Modular Avionics (IMA) modules. The main purpose of this standard is to define a general purpose application executive (APEX) interface between the application and the operating system of an avionics computer resource.

The APEX interface specification is divided into several parts. Part 1 specifies the core functionality which shall be provided to support critical applications. Part 2 describes extensions to the standard which are not targeted for critical applications. Part 3 contains the conformity test specification.


30.09.2010 ACROSS Page 41 of 127

The product PikeOS-653 is a complete and fully compliant implementation of part 1 of the APEX specification based on the general purpose product PikeOS. The APEX implementation of PikeOS-653 is based on Draft 4 of supplement 2 to ARINC specification 653, August 25, 2005.

In addition to this, the concept of PikeOS-653 allows to integrate and execute one or more APEX partitions in parallel to other partitions providing other APIs like POSIX, Java or Linux. All partitions may utilize interpartition communication and all partitions underly PikeOS-653 health monitoring.

1.5.6 POSIX Personality for PikeOS

The POSIX personality for PikeOS implements the PSE51 profile of the IEEE Std 1003.13-1998 with some additional realtime extensions included and adds support for a PSE52 compliant file system.


n/a


Due to the virtualization structure of the system, there are two types of engineers working with PikeOS: The application developer usually only has access to a specific partition and its API, While the system integrator defines the architecture of the overall system (partitions etc.).

The system integrator has to configure the system via the Virtual Machine Initialization Table (vmit.xml). The PiK Configuration Editor provides a graphical interface to create/handle this XML file. As part of the integration project build, the vmit.xml file is compiled into a binary module, which is then included in the ROM image.


30.09.2010 ACROSS Page 42 of 127

11 OPT9: BEE Services [ED]


R 2.5.1 - R 2.5.31

11.2 Syntax

Model Detail This section provides the interface specification of the lightweight DDS.

Condition Type: Package: infrastructure

Class

A Condition is a root class for all the conditions that may be attached to a WaitSet. This basic class is specialized in three classes that are known by the middleware: GuardCondition, StatusCondition, and ReadCondition. A Condition has a trigger_value that can be TRUE or FALSE and is set automatically by the Service.

Connections

Connector Source Target Notes

Generalization Source -> Destination

Public

StatusCondition

Public

Condition


Public

GuardCondition

Public

Condition


Public

ReadCondition

Public

Condition

Attributes

Attribute Notes Constraints and tags


30.09.2010 ACROSS Page 43 of 127


trigger boolean

Protected

Default:

semaphore Semaphore

Protected

Default:

lock Object

Protected

Default:

Operations

Method Notes Parameters

Condition()

Public

getTriggerValue() boolean

Public

Returns the trigger value.

updateSemaphore() void

Protected

Semaphore

[in] semaphore

release() void

Protected


30.09.2010 ACROSS Page 44 of 127

DDSException Type:

Package: infrastructure

Class Exception

This is the exception that represents the errors that may be thrown by the dds.

Contains an error type, and an eventually nested exception that has generated the error.



Public

ResourceLimitException

Public

DDSException

Association Source -> Destination

Public

DDSException

Protected type

ErrorType

Attributes


serialVersionUID long

Private

Static Const

Default: 1L

type ErrorType

Protected

Default:


30.09.2010 ACROSS Page 45 of 127


nestedException Exception

Protected

Default:

Operations


DDSException()

Protected

DDSException()

Protected

String

[in] message

DDSException()

Protected

ErrorType

[in] type

getNestedException() Exception

Public

Root exception that has caused the problem.

getType() ErrorType

Public

Returns the error type.

GuardCondition Type:


Class Condition

A GuardCondition object is a specific Condition whose trigger_value is completely under the control of the application.

Connections



30.09.2010 ACROSS Page 46 of 127



Public

GuardCondition

Public

Condition

Operations


setTriggerValue() void

Public

Set the trigger value.

boolean

[in] value

QosPolicy Type:


Class Cloneable, Serializable

This is the abstract base class of all the qos policies of the DDS, a qos policy defines how a service has to be done. Every class that extends this one, must implement the "clone" method.

Connections



Public

ResourceLimitsQosPolicy

Public

QosPolicy


Public

DurabilityQosPolicy

Public

QosPolicy


Public

TransportPriorityQosPolicy

Public

QosPolicy


Public

LatencyBudgetQosPolicy

Public

QosPolicy


30.09.2010 ACROSS Page 47 of 127



Public

HistoryQosPolicy

Public

QosPolicy


Public

OwnershipStrengthQosPolicy

Public

QosPolicy


Public

TimeBasedFilterQosPolicy

Public

QosPolicy


Public

PartitionQosPolicy

Public

QosPolicy


Public

OwnershipQosPolicy

Public

QosPolicy


Public

DeadlineQosPolicy

Public

QosPolicy


Public

ReliabilityQosPolicy

Public

QosPolicy


Public

DbTablePersistencyPolicy

Public

QosPolicy


Public

LifespanQosPolicy

Public

QosPolicy

Attributes



30.09.2010 ACROSS Page 48 of 127



Private

Static Const

Default: 1L

name String

Protected

Default:

Operations


QosPolicy()

Protected

String

[in] name

Static search() T

Public

Utility method that returns the desired policy from a list, if the policy is not found null is returned.

List<QosPolicy>

[in] qosList

Class<T>

[in] type

clone() QosPolicy

Public

toString() String

Public

ResourceLimitException Type:


Class DDSException


30.09.2010 ACROSS Page 49 of 127

Exception thrown when the 'ResourceLimits' qos policy bounds are overtaken on a DataWriter by the application.

Connections



Public

ResourceLimitException

Public

DDSException

Attributes



Private

Static Const

Default: 1L

Operations


ResourceLimitException()

Protected

ErrorType

[in] type

WaitSet Type: Package: infrastructure

Class

A WaitSet object allows an application to wait until one or more of the attached Condition objects has a trigger_value of TRUE or else until the timeout expires.


30.09.2010 ACROSS Page 50 of 127

Attributes


conditions List<Condition>

Private

Default:

currentSemaphore Semaphore

Private

Default:

semaphoreLock Object

Private

Default:

Operations


WaitSet()

Public

attachCondition() void

Public

Attaches a Condition to the WaitSet. It is possible to attach a Condition on a WaitSet that is currently being waited upon (via the wait operation). In this case, if the Condition has a trigger_value of TRUE, then attaching the condition will unblock the WaitSet. Adding a Condition that is already attached to the WaitSet has no effect.

Condition

[in] condition


30.09.2010 ACROSS Page 51 of 127


detachCondition() boolean

Public

Detaches a Condition from the WaitSet.

Condition

[in] condition

waitFor() List<Condition>

Public

This operation allows an application thread to wait for the occurrence of certain conditions. If none of the conditions attached to the WaitSet have a trigger_value of TRUE, this operation will block suspending the calling thread. The result of the wait operation is the list of all the attached conditions that have a trigger_value of TRUE.

 The wait operation takes a timeout argument that specifies the maximum duration for the wait. If this duration is exceeded and none of the attached Condition objects is true, an empty list will returned.

long

[in] timeout

getConditions() List<Condition>

Public

Returns the list of conditions.

Listener Type: Package: infrastructure

Interface

This is the root interface of every entity's listener interface.

Connections



Public

TopicListener

Public

Listener


Public

DataReaderListener

Public

Listener


30.09.2010 ACROSS Page 52 of 127



Public

DataWriterListener

Public

Listener

DataWriter Type:

Package: publication

Interface DomainEntity

DataWriter allows the application to set the value of the data to be published under a given Topic. DataWriter only deal with the data-type of the Topic it is bounded. Data Writer acts as Provider party for a Data Distribution service session for the Topic it is bounded, i.e. the Topic Service Session.

Connections



Public

DataWriter

Public

DomainEntity

Operations


getPublisher() Publisher

Public

getTopic() Topic<T>

Public

registerInstance() InstanceHandle

Public

Inform the service the intention to publish samples of the indicated topic instance, this is an OPTIONAL operation, the topic instance is automatically registered on the first time a sample is published by 'write' method. It has no effect if the topic instance is already registered. An exception is thrown if the maximum number of instances predicted by the RESOURCE LIMITS is crossed.

T

[in] sample


30.09.2010 ACROSS Page 53 of 127


unregisterInstance() void

Public

Inform the service that no more samples of the indicated topic instance will be published, and the correspondent resources can be released.

 NOTE: use the 'waitForAcknowledgments' operation before to be sure that not yet sent samples will be deleted.

InstanceHandle

[in] handle

unregisterInstance() void

Public

Inform the service that no more samples of the indicated topic instance will be published, and the correspondent resources can be released.

 NOTE: use the 'waitForAcknowledgments' operation before to be sure that not yet sent samples will be deleted.

T

[in] sample

write() void

Public

This operation modifies the value of a data instance.

T the Data to be written.

[in] data

InstanceHandle The handle of the Instance to be updated. The value null can be used for the parameter handle. This indicates that the identity of the instance should be automatically deduced from the instance_data (by means of the key).

[in] handle

writeWithTimestamp() void

Public

Write a sample using the specified timestamp, and sample instance.

T

[in] data

InstanceHandle

[in] handle

long

[in] timestamp

write() void

Public

This method write a data sample, the topic instance of the sample is automatically detected by the system (it's equivalent to invoke 'write(data, null)').

T

[in] data


30.09.2010 ACROSS Page 54 of 127


writeWithTimestamp() void

Public

Write a sample using the specified timestamp, the sample instance is automatically detected.

T

[in] data

long

[in] timestamp

waitForAcknowledgments() boolean

Public

Waits the calling thread until all samples in the queue are propagated to the subscriptions.

@return true if the operation releases until the timeout, otherwise false.

long

[in] timeout

lookupInstance() InstanceHandle

Public

Returns the instance handle of the sample passed as parameter, null if the instance is not already registered.

T

[in] sample

getPublicationMatchedStatus() PublicationMatchedStatus

Public

Returns the publication matched status, that gives information about the remote subscriptions discovered.

getOfferedIncompatibleQosStatus() OfferedIncompatibleQosStatus

Public

Returns the offered incompatible qos status, that gives information about the remote subscriptions with incompatible qos discovered.

getOfferedDeadlineMissedStatus() OfferedDeadlineMissedStatus

Public

Returns the offered deadline missed status, that gives information about the times that the data samples are not published like expected.

DataWriterListener Type: Package: publication

Interface Listener

Interface that must be implemented by a datawriter's listener.


30.09.2010 ACROSS Page 55 of 127

Connections



Public

DataWriterListener

Public

Listener

Realisation Source -> Destination

Public

DataWriterListenerImpl

Public

DataWriterListener


Public

PublisherListener

Public

DataWriterListener

Operations


onOfferedIncompatibleQos() void

Public

A QosPolicy value was incompatible with what was requested.

DataWriter<?>

[in] writer

OfferedIncompatibleQosStatus

[in] status

onPublicationMatched() void

Public

The DataWriter has found DataReader that matches the Topic and has compatible QoS, or has ceased to be matched with a DataReader that was previously considered to be matched.

DataWriter<?>

[in] writer

PublicationMatchedStatus

[in] status

onOfferedDeadlineMissed() void

Public

Deadline missed.

DataWriter<?>

[in] writer

OfferedDeadlineMissedStatus

[in] status

DataSample Type: Class


30.09.2010 ACROSS Page 56 of 127

Package: subscription

Class that implements a data sample. It contains the sample and the sample info object associated.

@param <T> the data type of the sample

Connections



Public

DataSample

Private sampleInfo

SampleInfo

Attributes


data T

Private

Default:

sampleInfo SampleInfo

Private

Default:

Operations


DataSample()

Public

T

[in] data

SampleInfo

[in] info


30.09.2010 ACROSS Page 57 of 127


getData() T

Public

The data sample.

getSampleInfo() SampleInfo

Public

The sample info object.

QueryCondition Type:


Class ReadCondition

This condition triggers each time that a sample that match the filter expression is received.

Connections



Public

QueryCondition

Public

ReadCondition

Operations


QueryCondition()

Protected

DataReader<?>

[in] reader

getQueryExpression() String

Public

Returns the filter expression.

setQueryExpression() void

Public

Set the filter expression.

String

[in] expression

ReadCondition Type: Package: subscription

Class Condition


30.09.2010 ACROSS Page 58 of 127

This condition triggers each time that a sample is received.



Public

ReadCondition

Public

Condition


Public

QueryCondition

Public

ReadCondition

Attributes


reader DataReader<?>

Protected

Default:

Operations


ReadCondition()

Protected

DataReader<?>

[in] reader

getDataReader() DataReader<?>

Public

Returns the data reader which this condition belongs to.

SampleInfo Type: Package: subscription

Class


30.09.2010 ACROSS Page 59 of 127

Class that provides informations about a sample of data.

Connections



Public

SampleInfo

Private publicationHandle

InstanceHandle


Public

SampleInfo

Private instanceHandle

InstanceHandle


Public

DataSample

Private sampleInfo

SampleInfo


Public

SampleInfo

Private sampleStateKind

SampleStateKind

Attributes


sampleStateKind SampleStateKind

Private

Default:

sourceTimestamp long

Private

Default:


30.09.2010 ACROSS Page 60 of 127


instanceHandle InstanceHandle

Private

Default:

publicationHandle InstanceHandle

Private

Default:

Operations


SampleInfo()

Public

SampleStateKind

[in] sampleStateKind

long

[in] sourceTimestamp

InstanceHandle

[in] instanceHandle

InstanceHandle

[in] publicationHandle

getSampleStateKind() SampleStateKind

Public

Returns the sample state, that indicates if the sample is already read.

getSourceTimestamp() long

Public

The timestamp on which the sample was published.


30.09.2010 ACROSS Page 61 of 127


getInstanceHandle() InstanceHandle

Public

The handle of the topic instance which the sample belongs to.

getPublicationHandle() InstanceHandle

Public

The handle of the writer that published the sample.

DataReader Type:


Interface DomainEntity

A DataReader allows the application (1) to declare the data it wishes to receive (i.e., make a subscription) and (2) to access the data received by the attached Subscriber. A DataReader refers to exactly one TopicDescription that identifies the data to be read. The subscription has a unique resulting type. The data-reader may give access to several instances of the resulting type, which can be distinguished from each other by their "key". The DataReader can access the "data" multiple times until all the previous access are "read" operations. When there is a "take" access, the DataReader will no longer able to access the data with "take" or "read" operations.

Connections



Public

DataReader

Public

DomainEntity

Operations


getSubscriber() Subscriber

Public

Returns the subscriber object which the reader belongs to.

getTopic() TopicDescription<T>

Public

Returns the topic attached to this reader.


30.09.2010 ACROSS Page 62 of 127


read() List<DataSample<T>>

Public

This operation accesses a collection of Data values from the DataReader. The size of the returned collection will be limited to the specified maxSamples.

 The samples are ordered from the older to the newest ones, first are placed the already accessed samples, then the not accessed samples.

int

[in] maxSamples

readWithCondition() List<DataSample<T>>

Public

 This operation accesses a collection of Data values from the DataReader. The size of the returned collection will be limited to the specified maxSamples.

 Only the samples that match with the condition will be included in the list. This operation is useful in association with a 'QueryCondition', in order to filter the results.

int

[in] maxSamples

ReadCondition

[in] condition

take() List<DataSample<T>>

Public

The "take" operations means that the application take full responsibility for the data; the DataReader will not be able to access the data by the "read" operations. This operation accesses a collection of data-samples from the DataReader and a corresponding collection of SampleInfo structures. The act of taking a sample removes it from the DataReader so it cannot be read or taken again.

 The samples are ordered from the older to the newest ones.

int

[in] maxSamples

takeWithCondition() List<DataSample<T>>

Public

This operation is similar to 'readWithCondition', but the samples will be no more accessible by the 'DataReader'.

int

[in] maxSamples

ReadCondition

[in] condition

readInstance() List<DataSample<T>>

Public

This operation accesses a collection of Data values from the DataReader. The behavior is identical to read except that all samples returned belong to the single specified instance whose handle is the parameter handle. Upon successful return,

int

[in] maxSamples

InstanceHandle

[in] handle


30.09.2010 ACROSS Page 63 of 127


the Data collection will contain samples all belonging to the same instance. The semantics are the same as for the read operation, except in building the collection the DataReader will check that the sample belongs to the specified instance and otherwise it will not place the sample in the returned collection.

takeInstance() List<DataSample<T>>

Public

This operation accesses a collection of Data values from the DataReader. The behavior is identical to take except for that all samples returned belong to the single specified instance whose handle is the parameter handle. This operation is analogous to readInstance except it accesses samples via the take operation.

int

[in] maxSamples

InstanceHandle

[in] handle

readNextSample() DataSample<T>

Public

This operation copies the next, non-previously accessed Data value from the DataReader; the operation also copies the corresponding SampleInfo. The implied order among the samples stored in the DataReader is the same as for the read operation. The readNextSample operation is semantically equivalent to the read operation where the input Data sequence has maxSamples=1 and view state is not read. The readNextSample operation provides a simplified API to read samples avoiding the need for the application to manage sequences. If there is no unread data in the DataReader, the operation will return null and nothing is copied.

takeNextSample() DataSample<T>

Public

This operation copies the next, non-previously accessed Data value from the DataReader and removes it from the DataReader so it is no longer accessible. This operation is analogous to reaNextSample except it accesses samples via the take operation.

createReadCondition() ReadCondition

Creates a read condition attached to this "DataReader".


30.09.2010 ACROSS Page 64 of 127


Public

deleteReadCondition() void

Public

Detach the read condition.

ReadCondition

[in] condition

createQueryCondition() QueryCondition

Public

Creates a query condition with the specified filter expression.

String

[in] queryExpression

getSampleLostStatus() SampleLostStatus

Public

Returns the sample lost status, that gives information about the samples lost during the communication with a data writer.

getSubscriptionMatchedStatus() SubscriptionMatchedStatus

Public

Returns the subscription matched status, that gives information about the remote publication discovered.

getRequestedIncompatibleQosStatus() RequestedIncompatibleQosStatus

Public

Returns the requested incompatible status, that gives information about the remote publications with incompatible qos discovered.

getSampleRejectedStatus() SampleRejectedStatus

Public

Returns the sample rejected status, that gives information about the samples rejected for overtaking the resource limits bounds.

getRequestedDeadlineMissedStatus() RequestedDeadlineMissedStatus

Public

Returns the requested deadline missed status, that gives information about the times that the data samples are not arrived like expected.

DataReaderListener Type: Package: subscription

Interface Listener

Root interface of the data reader's listeners. There are two kind of listeners for the data reader: the typed listener and the untyped listener.


30.09.2010 ACROSS Page 65 of 127

The typed listener makes use of the generics and permits to avoid explicit type cast. The same listener cannot be used by various data readers which have different data types, while the untyped listener can (but are explicit type cast must be used).

Connections



Public

DataReaderListener

Public

Listener

Realisation Source -> Destination

Public

DataReaderListenerImpl

Public

DataReaderListener


Public

UntypedDataReaderListener

Public

DataReaderListener


Public

TypedDataReaderListener

Public

DataReaderListener

Operations


onDataAvailable() void

Public

A new sample is available on the data reader.

DataReader<T>

[in] reader

onRequestedIncompatibleQos() void

Public

A data reader has received a request by a remote publication with incompatible qos.

DataReader<T>

[in] reader

RequestedIncompatibleQosStatus

[in] status

onSampleLost() void

Public

A sample is lost during the transmission for a data reader.

DataReader<T>

[in] reader


30.09.2010 ACROSS Page 66 of 127

Method Notes Parameters SampleLostStatus

[in] status

onSubscriptionMatched() void

Public

A matched publication is found.

DataReader<T>

[in] reader

SubscriptionMatchedStatus

[in] status

onSampleRejected() void

Public

A sample is rejected.

DataReader<T>

[in] reader

SampleRejectedStatus

[in] status

onRequestedDeadlineMissed() void

Public

Deadline missed.

DataReader<T>

[in] reader

RequestedDeadlineMissedStatus

[in] status

TypeSupport Type:

Package: topic

Class Serializable

Class that should be extended by all the data classes that belong to the data dictionary, that is the classes that can be used to share data by the middleware and linked with the topics.

If a data type that does not extend this class is attached to a topic, the default java serialization will be used instead the optimized internal dds serialization. The optimized serialization produces packets much more smaller than the default serialization, but requires much restrictive conditions on the data type.

The attributes of the data type can be: primitive types and strings, other classes that extends this class and respect these conventions, otherwise arrays of these types.

Each attribute must not be 'null', if the attribute is an array, each element of the array must not be 'null'.

Attributes



30.09.2010 ACROSS Page 67 of 127



Private

Static Const

Default: 1L

DDSKey Type: Package: topic

Interface

Annotation that can be used by the user in the data classes code to indicate to DDS which is the key that defines the instances of the data type. This annotation must be used in methods that have no parameters as arguments, and returns one of the following types: long, int, char, byte. Here is an example:

public class Temperature implements Serializable { private static final long serialVersionUID = 1L; private int sensorID; private double value; public Temperature(int sensorID, double value) { this.sensorID = sensorID; this.value = value; } @DDSKey public int getSensorID() { return sensorID; } public double getValue() { return value; } }

Tagged Values

annotations = @Retention(RetentionPolicy.RUNTIME)@Target(ElementType.FIELD).

11.3 Protocol

Two interaction models are shown here to illustrate the behavior of the DCPS. The first one concerns publication, the second one subscription.

Publication view

The first part of Figure shows the Publisher’s creation. The second part shows that topics must be created before they are referred to by a DataWriter.

The third shows the DataWriter’s creation. Then, a write and a dispose operation are issued on the


30.09.2010 ACROSS Page 68 of 127

DataWriter, which immediately informs the Publisher.


30.09.2010 ACROSS Page 69 of 127

Subscription view On the subscription side, two diagrams are given. The first one shows how it works when listeners are used, while the second shows the use of conditions and wait-sets.

Notification via Listeners

The first part of Figure shows the Subscriber’s and the DataReader’s creation by means of the DomainParticipant.

The second part shows the use of a SubscriberListener: It must first be created and attached to the Subscriber. Then when data arrives, it is made available to each related DataReader. Then the SubscriberListener is triggered. The application must then get the list of affected DataReader objects then it can read/take the data directly on these objects.

Alternatively, the third part of the diagram shows the use of DataReaderListener objects that are first created and attached to the readers. When data is made available on a DataReader, the related listener is triggered and data can be read (read/take). It should be noted that, in this case, no link between readers can be retrieved.


30.09.2010 ACROSS Page 70 of 127

Notifications via Conditions and Wait-Sets

The first part of Figure shows the Subscriber’s and the DataReader’s creation by means of the DomainParticipant.

The second part shows the creation of a WaitSet and a ReadCondition, the attachment of the latter to the former, and the call to the wait operation. Note that it is likely that several conditions (ReadCondition, but also StatusCondition) will be created and attached to the same WaitSet.


30.09.2010 ACROSS Page 71 of 127

The third part of the diagram shows the information flow when data is received. Note that the wait returns the list of all the enabled conditions, in an arrival cycle: in case several DataReader objects receive available data, several conditions will be set enabled at the same time and the application will perform several read accordingly.

Note – With conditions and wait-sets, read operations are executed naturally in the user context.


30.09.2010 ACROSS Page 72 of 127


11.5 Description

The Emerging Scenario

A new technology is becoming part of everyday life: pervasive, real-time data. This pervasive real-time infrastructure can be thought as an evolution of the Internet with the new capability to connect devices (at very high speed), rather than people (at human speed). Just as the “web” connects people and fundamentally changed how we all interact, pervasive data will connect devices and will change the way they interact.

Figure 2 depicts a possible Pervasive Real-Time Scenario where information shall be available anytime at any place regardless of its origin. Real-time middleware is the technological key driving this transformation.

Figure 2 – A Possible Pervasive Real-Time Scenario: Territory Surveillance

The Real-Time Data Distribution Standard

“Real-Time Data Distribution Services” (RT-DDS) is an open-architecture for real-time middleware specified by the Object Management Group (OMG). It is a sophisticated technology that implements a real-time publish-subscribe communication model and allows distributed processes to share data transparently among peer entities. It includes a complete set of Quality of Service (QoS) parameters for a complete control of the service performances and resource allocation.

RT-DDS publish-subscribe model allows for sending and receiving data, events, and commands among the nodes. Nodes that are producing information (publishers) create "topics" (temperature and pressure in fig.2) and publish "samples". The RT-DDS delivers the sample to all of those subscribers which declare an interest in that topic and that are compliant with the requested QoS. Any node can be publisher, subscriber, or both simultaneously.

BEE LegacyDataBase

Strategic Operation Centre

Air SegmentBEE

BEE

Data BaseData Base

Sea SegmentVHF

HiperLan

VHF

MPLS

GPSGPS

VHF

WiMax

WiFi + VHF

SensorNetworks

VHFVHF

Data BaseData Base

Ground Segment


30.09.2010 ACROSS Page 73 of 127

Figure 3 – A Possible Use of RT-DDS Protocol

Applications that use RT-DDS for their communications are entirely decoupled, therefore the designer shall spent very little effort on interface definition and testing, even in case of complex systems, e.g. System of Systems. RT-DDS autonomously handles all aspects of message delivery without requiring any intervention from the application.

This is made possible by RT-DDS allowing the user to specify QoS parameters as a way to (i) configure automatic-discovery mechanisms and (ii)specify the behavior adopted in sending and receiving messages.

The SSI RT-DDS Product: BEE

Space Software Italia developed BEE™, a real-time middleware which is an implementation of the OMG’s Real-Time Data Distribution Service (RT-DDS), including both Data-Centric Publish-Subscribe (DCPS) and Real-Time Publish Subscriber Wire Protocol (RTPS) layers. BEE provides all of the RT-DDS functions specified by the standard, and it is specifically optimized for mobile, mission critical applications where predictability, dependability, and security are key system requirements.

BEE includes proprietary solutions to improve the OMG’s suite of QoS parameters addressing:

• Timing Requirements: data lifetime, data delivery deadline, maximum/minimum transmission rate at both sender and recipient endpoints;

• Availability requirements: resilient data delivery, data persistence in the system despite the fault of its source, data distribution service availability via the hot swap of backed-up data sources;

• Partitioning which allows to split the system into separate data domains.

Predictable Data Distribution

BEE™ Main Features

• Multi-level Resource Management

• Dynamic Network Resource Allocation

• Data Classification and Shaping

• Session Admission Control

• Robustness to Intermittent Networks

SatelliteMPLS

PublisherPublisherSubscriberSubscriber

SubscriberSubscriber

SensorTemperature Sensor

PressureApplication Application

DataWriter

<Temperature>

DataWriter

<Temperature>

DataWriter

<Pressure>

DataWriter

<Pressure>

DataReader

<Temperature>

DataReader

<Temperature>

DataReader

<Pressure>

DataReader

<Pressure>

DataReader

<Temperature>

DataReader

<Temperature>

QoSTCP/IP

QoSMANET VHF

Real Time Publish SubscribeReal Time Publish Subscribe

QoS Contract


30.09.2010 ACROSS Page 74 of 127

• Ready for TACOMS standard for IP QoS (STANAG 4644)

Resilient Data Distribution • No single point of failure (Serveless Architecture)

• Embedded Reliable protocol (only Unicast)

• Serverless Data Persistence

• Serverless Data Source Hot Redundancy

Secure Data Distribution Services • Domain Access Control

• Topic Access Control

• Secure Discovery Protocol

Low Network Overhead • Low Overhead Data Exchange Protocol

• Offline Configuration for Static Network

• Differentiated Physical Network Support for Management and User Traffic

Model-Driven Architecture


Overall Description

BEE allows notifying the application a set of events which related to the service provisioning.

The events which can be communicated to the application depend on the BEE Entity.

The events can be grouped into two families, (i) the Read communication events, and (ii) the Plain communication events.

Read communication events

The Read communication events relates to arrival of data.

The table below lists the Read communication events for each BEE Entity:

Entity Event name Description

DataReader DataAvailable

A new data sample is available and ready to be read.


30.09.2010 ACROSS Page 75 of 127

SampleLost Some data samples have been lost.

SampleRejected A data sample has been rejected due to resource limit bounds.

RequestedDeadlineMissed A data sample is not arrived within the deadline timeout bound.

DataWriter OfferedDeadlineMissed

A data sample has not been published by the application within the deadline timeout bound.

Plain communication events

The Plain communication events provide information about the service provisioning statuses.

The table below lists the Plain communication events for each BEE Entity.

Entity Event name Description

Topic InconsistentTopic

A remote topic with the same name but different data type has been discovered.

DataReader SubscriptionMatched A remote writer has been discovered.


30.09.2010 ACROSS Page 76 of 127

RequestedIncompatibleQos

A remote writer with incompatible QoS has been discovered.

DataWriter PublicationMatched A remote reader has been discovered.

OfferedIncompatibleQos A remote reader with incompatible QoS has been discovered.

This information is provided via the Status object, i.e. for each plain communication events is related a Status object which stores the information about that event occurrence. The table below lists the events and the related Status information.

Status/Attibute Attribute meaning

SampleLostStatus

totalCount Total cumulative count of all samples lost across of instances of data published under the Topic.

totalCountChange

The incremental number of samples lost since the last time the listener was called or the status was read.

SampleRejectedStatus

totalCount Total cumulative count of samples rejected by


30.09.2010 ACROSS Page 77 of 127

the DataReader

totalCountChange The incremental number of samples rejected since the last time the listener was called or the status was read.

lastReason Reason for rejecting the last sample rejected. If no samples have been rejected, the reason is the special value NOT_REJECTED.

lastInstanceHandle Handle to the instance being updated by the last sample that was rejected.

InconsistentTopicStatus

totalCount

Total cumulative count of the Topics discovered whose name matches the Topic to which this status is attached and whose type is inconsistent with the Topic.

totalCountChange The incremental number of inconsistent topics discovered since the last time the listener was called or the status was read.


totalCount

Total cumulative number of missed deadlines detected for any instance read by the DataReader. Missed deadlines accumulate; that is, each deadline period the totalCount will be incremented by one for each instance for which


30.09.2010 ACROSS Page 78 of 127

data was not received.

totalCount_ change The incremental number of deadlines detected since the last time the listener was called or the status was read.

lastInstanceHandle Handle to the last instance in the DataReader for which a deadline was detected.


totalCount

Total cumulative number of times the concerned DataReader discovered a DataWriter for the same Topic with an offered QoS that was incompatible with that requested by the DataReader.

totalCountChange The change in totalCount since the last time the listener was called or the status was read.

lastPolicyType The QosPolicy class of one of the policies that was found to be incompatible the last time an incompatibility was detected.

policies

A list containing for each policy the total number of times that the concerned DataReader discovered a DataWriter for the same Topic with an offered QoS that is incompatible with that requested by the DataReader.


30.09.2010 ACROSS Page 79 of 127

OfferedDeadlineMissedStatus

totalCount

Total cumulative number of offered deadline periods elapsed during which a DataWriter failed to provide data. Missed deadlines accumulate; that is, each deadline period the totalCount will be incremented by one.


lastInstanceHandle Handle to the last instance in the DataWriter for which an offered deadline was missed.

OfferedIncompatibleQosStatus

totalCount

Total cumulative number of times the concerned DataWriter discovered a DataReader for the same Topic with a requested QoS that is incompatible with that offered by the DataWriter.


lastPolicyType The Policy class of one of the policies that was found to be incompatible the last time an incompatibility was detected.


30.09.2010 ACROSS Page 80 of 127

policies

A list containing for each policy the total number of times that the concerned DataWriter discovered a DataReader for the same Topic with a requested QoS that is incompatible with that offered by the DataWriter.

PublicationMatchedStatus

totalCount

Total cumulative count the concerned DataWriter discovered a “match” with a DataReader. That is, it found a DataReader for the same Topic with a requested QoS that is compatible with that offered by the DataWriter.


lastPublicationHandle Handle to the last DataReader that matched the DataWriter causing the status to change.

currentCount The number of DataReaders currently matched to the concerned DataWriter.

currentCountChange The change in currentCount since the last time the listener was called or the status was read.

SubscriptionMatchedStatus

totalCount Total cumulative count the concerned DataReader discovered a “match” with a


30.09.2010 ACROSS Page 81 of 127

DataWriter. That is, it found a DataWriter for the same Topic with a requested QoS that is compatible with that offered by the DataReader.


lastPublicationHandle Handle to the last DataWriter that matched the DataReader causing the status to change.

currentCount The number of DataWriters currently matched to the concerned DataReader.

currentCountChange The change in currentCount since the last time the listener was called or the status was read.

Listeners

The event notification is performed via an abstract interface, the Listener. This interface allows the access to a set of methods, each serving a specific event to be notified. On event occurrence, the BEE will invoke the specific Listener method. Listeners are interfaces that the application must implement.

BEE guarantees that every method of a listener will be invoked sequentially and each time the related event will occur. A concurrent execution will happen only if the same listener is used from more entities. For that reason, the methods implementation shall be NOT blocking.

For each event, the table below lists the involved listeners and the related method.


30.09.2010 ACROSS Page 82 of 127

Event name Status Listeners Method name

DataAvailable -

DataReaderListener, SubscriberListener, DomainParticipantListener

onDataAvailable

SampleLost SampleLostStatus


onSampleLost

SampleRejected SampleRejectedStatus


onSampleRejected

OfferedDeadlineMissed OfferedDeadlineMissedStatus

DataWriterListener, PublisherListener, DomainParticipantListener

onOfferedDeadlineMissedStatus

RequestedDeadlineMissed



onRequestedDeadlineMissedStatus

PublicationMatched SubscriptionMatchedStatus


onSubscriptionMatched

SubscriptionMatched PublicationMatchedStatus DataWriterListener, PublisherListener, DomainParticipantListen

onPublicationMatched


30.09.2010 ACROSS Page 83 of 127

er

RequestedIncompatibleQos



onRequestedIncompatibleQos

OfferedIncompatibleQos OfferedIncompatibleQosStatus

DataWriterListener, PublisherListener, DomainParticipantListener

onOfferedIncompatibleQos

InconsistentTopic InconsistentTopicStatus TopicListener, DomainParticipantListener

onInconsistentTopic

For each entity's listener, there is an utility class implementing that interface and providing the default behaviour (do nothing) for each event. These classes are useful because it's possible to extends one of them and override only the methods of interest without writing the others, in case the application needs to handle only some events. The class name can be built by adding the suffix 'Impl' to the listener name, for example SubscriberListenerImpl or DomainParticipantListenerImpl.


System parameters

Below are listed the system parameters of the BEE, enclosed in parenthesis are the default values. All the time values are in milliseconds.

The parameters are loaded from the file ‘ddsConfiguration.xml’, that has to be placed in the root directory of execution. If the configuration file is not found, the default values are used.

The file format is the standard “java.util.Properties” xml file, described by: “ ://java.sun.com/dtd/properties.dtd”.

http://java.sun.com/dtd/properties.dtd�


30.09.2010 ACROSS Page 84 of 127

The values are set during the first ‘getInstance()’ invocation on the DomainParticipantFactory, and it’s not possible to change them after that.

It's possible to set the parameters by the application before the ‘getInstance()’ initialization in this way:

System.setProperty("PacketBufferSize", "" + 65536);

For each parameter, first is searched an eventually value set by the application, then the value indicated in the configuration file, and ultimately the default value.

Main parameters

• EnableMulticast (false)

The multicast working mode is enabled if the value is true,.

• PacketTimeout (500)

The time within the acknowledgement is expected, after this time the packet is retransmitted.

Shorter values can increase the speed of communication, but can generate traffic congestion if it’s too short. It should be chosen considering the transmission latency and the error probability of the network.

• TotalPacketTimeout (UNLIMITED)

Total time after that the retransmission tries are terminated and the packet is declared lost.

• DiscoveryInitialCycleDelay (1000)

Time interval on which the participant discovery signal is sent in the initial phase, that is just the domain participant is created. After the number of times specified by the 'DiscoveryInitialAttempts' parameter, the time interval will become the value indicated by the 'DiscoveryCycleDelay' parameter.

The reason because there are two different sending frequency is to permit to optimize the bandwidth utilization. Initially is advisable to choice a short delay to make sure that all the peers in the distributed system discover themselves, while at steady state the value can be dilated to reduce the network traffic. It can be selected an infinite value for the second delay if it is enough certain that all the peers will receive the packet after the tries of the initial phase.

See the figure 2 below to see a graphical explanation.


30.09.2010 ACROSS Page 85 of 127

• DiscoveryInitialAttempts (10)

Number of times that the participant discovery packet is sent with the 'DiscoveryInitialCycleDelay' interval, then the interval will become 'DiscoveryCycleDelay'.


• DiscoveryCycleDelay (10000)

Time interval on which the participant discovery signal is sent after the initial phase.


Figure 1

• UndiscoveryCycleDelay (30000)

Time interval on which the alive request message is sent to verify that a remote entity that matches a local entity is still alive.

A great value can reduce the bandwidth utilization, but the removal of expired entity will become slow. It can be chosen an infinite value, to not generate traffic, but the remote entities will NEVER removed.

Consider that the keep alive signal is not sent if is detected an activity by the remote entity (like an acknowledgment), so the data sample rate publication can be keep in consideration to choice this parameter.

• DiscoveryPacketTotalTimeout (30000)

The same behaviour as TotalPacketTimeout, but specific for the discovery data.


30.09.2010 ACROSS Page 86 of 127

This is important because it determines the timeout after that a remote peer is considered dead if it doesn’t respond to the keep alive requests.

• DiscoveryPacketTimeout (500)

The same behaviour as PacketTimeout, but specific for the discovery data. It’s advisable to choice the same value of ‘PacketTimeout’ if there aren’t specific requirements.

• DiscoveryParticipantDelay (2000)

Time that the middleware blocks the application during the ‘createParticipant’ operation to let the discovery work.

This is optional, this value can be set to 0 to avoid the pause. But if this parameter is great enough to be sure that the participant discovery data has reached all the other peers, and the eventually acknowledgements are received, so it is guaranteed that the communication between data writers and readers will begin immediately.

• SynchronizedClocks(false)

This parameter affects the behaviour of the qos policy lifespan on reader side. If it’s set to true, the same expiration time defined by the writer that has published the sample is utilized, otherwise the expiration time is computed by adding the lifespan duration value to the current system timestamp.

Other parameters

• RedundancyLevel

This parameter affects the behaviour of the middleware for the Ownership policy in exclusive kind. The ‘1’ value means that only the owner of a data instance transmit data to the DataReader (on steady state, during transitions it couldn’t be true), while a ‘2’ means that two writers are transmitting data simultaneously (the reader accept only samples from the owner and drop the others), and so on. The value ‘-1’ means that all the writers transmit samples, the ownership will be realized by filtering on the reader size.

Use the value ‘1’ to minimize the network traffic, whereas a different value permit to minimize the recovery time in case of failure.

• InitialPortNumber

Initial port for the port range used by the middleware. Peers with different values for this parameter cannot work together, so this parameter must be changed with caution!

• PortRangeWidth

Width of the port range used by the middleware, so the port range that will be used is from the value indicated by 'InitialPortNumber' to that value plus 'PortRangeWidth'


30.09.2010 ACROSS Page 87 of 127

• MaximumAppsNumber

Maximum number of contemporaneously running applications on the machine that use the middleware. The port range is divided in equal shares for each possible application.

• PacketBufferSize (65536)

Maximum size of the data packet manageable by the dds.

• PacketRetryDelay (500)

Time after that the middleware try to retransmit a packet after an hardware problem.

• DiscoveryPacketRetryDelay (500)

The same behaviour as PacketRetryDelay, but specific for the discovery data.

• DatabaseName (“DdsData”)

The name of the database for the embedded dbms, created if necessary.

• MaxTextLength (1024)

The maximum size of the textual fields for the tables of the embedded db.

Network configuration

The network configuration includes:

• Define the set of addresses on which the distributed system works, used by the discovery to search the other peers.

• Define the multicast group addresses utilized by the middleware (necessary only in the multicast working mode, these values are ignored in the other case).

The settings are configurable by domain, each domain can have its own configuration.

The network configuration is loaded from the file “networkConfiguration.xml”, that has to be placed in the ROOT directory of execution. If the file is not found, the default values are used. It’s not possible to change these values by the application.

Here is an example of configuration file:

<?xml version="1.0" encoding="UTF-8"?>


30.09.2010 ACROSS Page 88 of 127

<networkConfiguration>



<default networkInterface="" multicastDiscovery="229.0.0.1" defaultMulticastTopicData="229.0.0.2">

<discoveryAddress>255.255.255.255</discoveryAddress>

<discoveryAddress>localhost</discoveryAddress>

</default>



<domain id="88888" networkInterface="10.180.2.0/24"

multicastDiscovery="229.0.0.3" defaultMulticastTopicData="229.0.0.4">



<topic name="temperature" multicastData="229.0.0.3" />

</domain>

</networkConfiguration>

The default tag defines the default settings for all the domains. If there aren’t specific domain settings, these will be used.

The networkInterface attribute defines which network interface has to be used. Different domains can use different network interfaces simultaneously

If this parameter is not set or empty, the middleware will determine automatically the network interface to use. The network interface will be chosen by detecting the ip address bounded with the hostname “localhost”.

. The network interface can be indicated by using the local ip address used to access the network (for example “10.180.2.6”) or the network address in the form address/netmask (for example “10.180.2.0/24”). The second way permits to reuse the same configuration file on different machines, the middleware will detect automatically the ip address to use.

Each discoveryAddress tag defines an address on which the discovery component will search other peers. The set of the addresses defined by this tag should compose the set of addresses on which the system works. It can be used unicast addresses (ip or hostname), or a broadcast addresses

The multicastDiscovery attribute defines the multicast address used by the discovery for a domain. The same address can be used for different domains. The default value is “229.0.0.1”.

. If no one value is set, there are used the values: “localhost” and “255.255.255.255”.


30.09.2010 ACROSS Page 89 of 127

The defaultMulticastTopicData defines the default multicast address that will be used for the transmission of the data samples for a topic, if there aren’t specific settings for that topic. The default value is “229.0.0.2”.

The same multicast address can be used for several topics, but it’s advisable that each topic uses its own multicast address.

The topic tag permits to define the multicast address to use for the data samples of a topic.

QoS Configuration

The network configuration permits to define the mapping of the transport priority level to the TOS value that will be used to deliver the data samples.

The configuration is loaded from the file “qosConfiguration.xml”, that has to be placed in the ROOT directory of execution. If the file is not found, the default values are used. It’s not possible to change these values by the application.

This is an example configuration file:

<?xml

version="1.0" encoding="UTF-8"?>

<qosConfiguration defaultTos="0">

<priority aboveLevel="10" defaultTos="50" />

<priority aboveLevel="50" defaultTos="0x0F" />

</qosConfiguration>

The ‘defaultTos’ attribute of the ‘qosConfiguration’ tag specifies the TOS value if the transport priority policy is not defined or 0.

The tag priority specifies the TOS value that will be suited for a priority level upper than the level indicated by the ‘aboveLevel’ tag. The TOS value can be expressed in decimal form, or in hexadecimal form by preceding it with the ‘0x’ string.

For the previous example the TOS value 0 will be used if transport priority is lower than 10, 50 if the priority is major (or equal) than 10 and lower than 50, 16 for a priority value of 50 and above.


30.09.2010 ACROSS Page 90 of 127

12 OPT10: Real-Time Tracing Service [LAUTERBACH]

For the following chapters various communication-interconnects will be employed to implement the specified functionality. The following conceptual figure depicts the various interconnects:

Figure 4: Interconnects used by Diagnostic Services

The following services rely on interconnects shown in Figure 4, marked with 1)-5). Note that the communication between Global Diagnostic Unit and Local Diagnostic Unit marked with 3) is provided by the TTNoC.


To support the development of a system it is beneficial to be able to trace several aspects of the complete system while the system is performing its regular function:

- TTNoC Trace: Record the occurrence and content of messages transmitted via the TTNoC.

- Memory Trace: Periodically record part of the state (i.e. memory content) of components connected to the TTNoC.


30.09.2010 ACROSS Page 91 of 127

12.2 Syntax

module TraceService { typedef long ComponentID; // identifies a component in the system // (component == one node connected to the TTNoC) typedef unsigned short PortID; // identifies a TTNoC Port of a specific component typedef long TraceID; // identifies an active trace struct ComponentRange { ComponentID low; ComponentID high; }; struct PortRange { PortID low; PortID high; }; struct MemoryRange { long long low; long long high; }; enum ErrorCode { SUCCESS, NOT_SUPPORTED, NO_BANDWIDTH, TOO_MANY_TRACES, UNKNOWN_COMPONENT, UNKNOWN_TRACE };


30.09.2010 ACROSS Page 92 of 127

interface TraceControl { ErrorCode addNetworkTrace( out TraceID id, // traceID associated with this trace in ComponentRange sender, // define range of traced senders in ComponentRange receiver, // define range of traced receivers in PortRange port, // define range of traced ports in long contentLength, // define how many bytes to trace from message content in long contentOffset // define offset into message content ); ErrorCode removeNetworkTrace(in TraceID id); // remove a network trace ErrorCode removeAllNetworkTraces(); // remove all network traces ErrorCode addMemoryTrace( out TraceID id, // traceID associated with this trace in ComponentID compID, // component for which to activate trace in MemoryRange memRange // memory range which should be traced ); ErrorCode removeMemoryTrace(out TraceID id); ErrorCode removeAllMemoryTraces(); }; };

12.3 Protocol

To get visibility into the system, an external tool connects to the Global Diagnostic Unit via the control interconnect marked with 2) in Figure 4. The external tool uses the control-interconnect to activate two different types of traces:

• Traces of messages routed through the TTNoC, by calling addNetworkTrace.

• Traces of memory content captured by the Local Diagnostic Unit of a component, by calling addMemoryTrace.

Once a trace is activated, the Global Diagnostic Unit uses the fast trace export interconnect, marked with 1) in Figure 4, to export captured data.

Information about messages routed through the TTNoC can be directly gathered by the Global Diagnostic Unit by listening to the traffic on the TTNoC.

Information about memory content of a component is gathered by the Local Diagnostic Unit of a component. The Global Diagnostic Unit uses the TTNoC (interconnect 3 in Figure 4) to forward the memory trace activation request to the appropriate Local Diagnostic Unit. The Local Diagnostic Unit locally accesses the memory (interconnect 5 in Figure 4) and sends collected memory trace information back through the TTNoC to the Global Diagnostic Unit, which in turn exports the information to the external tool.


This service depends on the core communication services, provided by the TTNoC.

To allow tracing the memory content of a component, the schedule of the TTNoC must allocate enough bandwidth for the Local Diagnostic Unit of the component, to enable the Local Diagnostic Unit to forward the collected memory trace information to the Global Diagnostic Unit.


30.09.2010 ACROSS Page 93 of 127

12.5 Description

By calling addNetworkTrace, and addMemoryTrace an external tool can activate the export of system internal information. A system developer can use the external tool to display and analyzer the captured information. This functionality is supposed to support the developer during system implementation. The service is not intended to be used as a part of the regular function of a system.


Not applicable. (The Real-Time Tracing Service is not part of the regular function of a system.)


To allow configuration of the Global Diagnostic Unit, information about all existing Components and their component ID is needed.


30.09.2010 ACROSS Page 94 of 127

13 OPT11: Debugging Service [LAUTERBACH]


To facilitate efficient development, developers often require stimulating and controlling various aspects of the system, bypassing the systems regular function.

The Debugging Service supports this kind of stimuli and control by giving an external tool access to the system for this purpose.

13.2 Syntax

module DebugService { typedef long ComponentID; // identifies a component in the system // (component == one node connected to the TTNoC) typedef unsigned short PortID; typedef sequence<octet> BinaryContent; enum ErrorCode { SUCCESS, NOT_SUPPORTED, UNKNOWN_COMPONENT, CPU_RUNNING, CPU_STOPPED, UNKNOWN_REGISTERINDEX, ACCESS_VIOLATION }; interface LDUControl { struct LDUMessage { ComponentID compID; long messageType; BinaryContent content; }; ErrorCode sendMessage(in LDUMessage message); }; interface MessageInjection { struct MessageDescriptor { ComponentID sender; ComponentID receiver; PortID port; BinaryContent content; }; ErrorCode injectMessage(in MessageDescriptor message); };


30.09.2010 ACROSS Page 95 of 127

interface CPUControl { enum CpuState { RUNNING, STOPPED }; // Content of all CPU registers // details are completely CPU specific typedef sequence<BinaryContent> CpuRegisters; ErrorCode setComponent(in ComponentID compID); // specify component to control ErrorCode stopCpu(); ErrorCode startCpu(in long flags); ErrorCode getCpuState(out CpuState state); ErrorCode getCpuRegisters(out CpuRegisters regs); ErrorCode setCpuRegister(in long index, in BinaryContent value); ErrorCode getMemory( in long long offset, in long long length, out BinaryContent memory ); ErrorCode setMemory( in long long offset, in long long length, in BinaryContent memory ); }; };

13.3 Protocol

To access a Local Diagnostic Unit, an external tool calls LDUControl.sendMessage via the control interconnect 2 in Figure 4. Since the functionality provided by the different Local Diagnostic Units is going to be vastly different, the Global Diagnostic Unit just passes the message on to the addressed Local Diagnostic Unit. The meaning and effect of the message completely depends on the specific Local Diagnostic Unit.

To inject a message into the TTNoC an external tool calls MessageInjection.injectMessage via the control interconnect 2 in Figure 4. The Global Diagnostic Unit injects the message into the TTNoC communication.

To gain control over the CPU of a component, an external tool calls the operations of CPUControl. The external tool first calls CPUControl.setComponent to select the component it wants to access. It then uses the various other operations of CPUControl to control the CPU of the component and to get information about register and memory content of the component. The Global Diagnostic Unit forwards the requested operations to the Local Diagnostic Unit via the TTNoC (interconnect 3 in Figure 4). The Local Diagnostic Unit uses a local interconnect to the CPU (interconnect 4 in Figure 4) to execute the operations.


30.09.2010 ACROSS Page 96 of 127


This service depends on the core communication services, provided by the TTNoC.

Support for the CPUControl interface requires, that the CPU of a component implements a suitable debug interface.

13.5 Description

The interfaces declared above refer to the communication between an external tool and the Global Diagnostic Unit. These Services are not intended to be used by functional software and are not part of the regular operation of a system.

The Debugging Service allows a developer to actively stimulate the system to inspect how the system reacts to the stimulus. For example: The Local Diagnostic Unit of a component can be used to stimulate faulty behavior and so allows testing the reaction of the system to such faulty behavior. Additionally the Local Diagnostic Unit might be used to modify and tune parameters of the system, while the system is executing its regular function.

The CPUControl interface provides the functionality to implement a classical software debugger, which gives the developer the ability to set breakpoints and to use single stepping to find and correct bugs in software.

While the real-time tracing service described in 0 gives a developer visibility of the TTNoC traffic, the MessageInjection interface provides the ability to actively influence the TTNoC traffic.


Not applicable. (The Debug Service is not part of the regular operation of a system.)


To use the specified interfaces, an external tool needs information about the components contained in the system.


30.09.2010 ACROSS Page 97 of 127

14 OPT12: Health Monitoring Service (Local DU) [LAUTERBACH]


To support Health Monitoring Services, the Local Diagnostic Unit (LDU) monitors health relevant data of a component (a component in this context means a node connected to the TTNoC). A LDU has a set of health properties which it can monitor. The LDU transmits the current values of the health properties to a set of receivers in periodic intervals via the TTNoC.

The set of receivers and the base interval period is implicitly defined by the schedule of the TTNoC.

The measurement and acquisition of the value of a health property can be either implemented in the LDU (in firm- or hardware) or it can be implemented in (functional) software running on the component. In the latter case the software has to communicate the acquired health property value to the LDU.

The Global Diagnostic Unit (which is the main intended receiver for health information) can log faults (values which indicate an unhealthy state) to non-volatile memory for maintenance support or it can take corrective actions (like rebooting a component).


30.09.2010 ACROSS Page 98 of 127

14.2 Syntax

module HealthMonitorService { typedef long ComponentID; // identifies a component in the system // (component == one node connected to the TTNoC) typedef long HandlerID; // ID for a property handler typedef long PropertyID; // identifies a health property which // a specific LDU can monitor typedef boolean PropertyState; // if true, the LDU is monitoring this property typedef long PropertyHealth; // indicates how healthy a property is, // 0 means "healthy", higher values mean unhealthy struct PropertyValue { boolean valid; // if "false", the property has no defined value PropertyHealth value; // specific for Property, 0 means "healthy" }; enum ErrorCode { SUCCESS, NOT_IMPLEMENTED, UNKNOWN_PROPERTY, UNKNOWN_COMPONENT, UNKNOWN_HANDLER, ACCESS_VIOLATION }; interface LocalDiagnosticUnit { // operations to activate and deactivate the monitoring of a property ErrorCode setPropertyState(in PropertyID id, in PropertyState state); ErrorCode getPropertyState(in PropertyID id, out PropertyState state); // operations to read and write a property value. // Intended to support software implemented health properties. ErrorCode setPropertyValue(in PropertyID id, in PropertyValue value); ErrorCode getPropertyValue(in PropertyID id, out PropertyValue value); }; /* ... */ };

14.3 Protocol

At reset, all health properties will be initialized to indicate that they are inactive (currently not monitored) and subsequently that there is no valid value, by setting the corresponding valid flag to false.

After reset, the LDU will start to monitor a set of (component specific) base properties. The PropertyState of these properties will become true (indicating that the LDU has started monitoring these properties). With the acquisition of the value of a health property the value of this property gets valid and the corresponding valid flag will be set to true.


30.09.2010 ACROSS Page 99 of 127

As the soft- or firmware of a component is booting up, it will activate the monitoring of more properties by calling setPropertyState. Additionally the soft- or firmware of a component might start to communicate the value of software implemented health properties to the LDU by calling setPropertyValue.

The LDU forwards collected property values to a set of receivers (implicitly configured by the schedule of the TTNoC). The Global Diagnostic Unit should be one of the receivers (corresponding to interconnect 3 in Figure 4).



While not strictly necessary, it is assumed that the Global Diagnostic Unit is one of the receivers of the health property values of all LDUs.

14.5 Description

Each component must specify a component specific set of health properties, which can be monitored by its local diagnostic unit. Because components can be anything (from a simple sensor to a complete CPU module) it is expected that the supported properties will vary from component to component.

The Local Diagnostic Unit is only responsible for collecting and forwarding data to the Global Diagnostic Unit and other components. Because of that, the Local Diagnostic Unit only allows to turn monitoring of different component specific health properties on or off.

Health properties can be either autonomously monitored by the Local Diagnostic Unit or they can be computed by the software (or firmware) running on the component. To support health properties which are computed by the soft- or firmware of the component, the interface of the Local Diagnostic Unit allows the soft- or firmware to update the current value of such a computed health property. The Local Diagnostic Unit is only responsible to forward this computed health property values to the Global Diagnostic Unit and other components.


There are two sets of properties: Properties which are only logged for later analysis and properties which might trigger a corrective action.

Properties which are only logged do not influence the behavior of the system, so a faulty measurement of such a property might confuse a maintenance engineer, but will not propagate to any other part of the system.

Properties which might trigger a corrective action are very different: If the Local Diagnostic Unit measures a wrong value of a health property, then all receivers of this property get a wrong indication about the health state of the property. If consequently a receiver triggers a corrective action, then the fault will propagate to all components influenced by the corrective action.

It is recommended that corrective actions only act on the component to which the Local Diagnostic Unit belongs; when following this recommendation a fault in recording a health property has the same consequences as the failure of the component in general, so in this case the component itself still forms a fault containment region.


30.09.2010 ACROSS Page 100 of 127

If a Local Diagnostic Unit monitors properties which might lead to corrective actions, then the Local Diagnostic Unit has exactly the same criticality as the rest of the component and must be verified in the same manner.


There needs to be a list of all components and the properties collected by the Local Diagnostic Units for these components.


30.09.2010 ACROSS Page 101 of 127

15 OPT13 Health Monitoring Service (Global DU) [LAUTERBACH]


The Global Diagnostic Unit is responsible for collecting health data from the Local Diagnostic Units (see 14).

The Global Diagnostic Unit offers the following features:

- Log faults to non-volatile memory (like FLASH or EEPROM)

- Export the collected log information for further processing

Additionally the Global Diagnostic Unit or other receivers of health property values might install handlers to trigger corrective actions.

15.2 Syntax

module HealthMonitorService { /* ... */ interface GlobalDiagnosticUnit { struct LogEntry { long long timestamp; ComponentID compID; PropertyID propID; PropertyValue value; }; typedef sequence<LogEntry> LogMemory; }; interface GlobalDiagnosticUnitInternal : GlobalDiagnosticUnit { ErrorCode enablePropertyLogging( in ComponentID compID, in PropertyID propID, in PropertyHealth threshold); ErrorCode clearLog(); ErrorCode readLog(out LogMemory log, in long maxEntries); }; interface GlobalDiagnosticUnitExternal : GlobalDiagnosticUnit { ErrorCode clearLog(); ErrorCode readLog(out LogMemory log, in long maxEntries); };


30.09.2010 ACROSS Page 102 of 127

interface PropertyHandler { void putPropertyValue(in PropertyID propID, in PropertyValue value); }; interface PropertyReceiver { ErrorCode registerHandler( out HandlerID handlerID, in ComponentID compID, in PropertyHandler handler); ErrorCode unregisterHandler(in HandlerID handlerID); }; };

15.3 Protocol

The Global Diagnostic Unit offers the generic service to log “unhealthy” health property values to non-volatile memory. If a health property should be activated for logging, the operation enablePropertyLogging is called. The calling parameters define for which component and for which health property the logging is enabled. The threshold parameter can be used to constrain the logging to values which are above the specified threshold. A threshold value of 0 logs all “unhealthy” values of a health property.

Only changes in health property values are logged.

Log entries identify the component and health property which was logged, a timestamp at which the entry was logged and the value of the health property.

Several interfaces are defined:

- The GlobalDiagnosticUnitInternal interface is intended to be used by software running inside the system (other components on the TTNoC etc.).

- The GlobalDiagnosticUnitExternal interface is intended to be used by an external tool connecting to the GlobalDiagnosticUnit via a dedicated interface. The tool uses the interface to read out the collected logging information.

Additionally the framework adds the functionality to install soft- or firmware handlers for propterty values: The PropertyReceiver interface can be implemented by all components which receive property values from the LDU (as configured by the schedule of the TTNoC). Firm- or Software running on a component can call PropertyReceiver.registerHandler to install a handler for the properties of a specific component. The handler must implement the PropertyHandler interface. The receiver will forward new values of properties from the specified component to the handler by calling PropertyHandler.putPropertyValue. The handler might then take appropriate actions.




30.09.2010 ACROSS Page 103 of 127

15.5 Description

The service provides two different functionalities. The logging functionality is for maintenance purposes. The intended usage is that a maintenance engineer reads out the logged information and can use the information to decide which maintenance actions are necessary.

The second functionality offers the installation of property handlers. The intent is that a property handler might take corrective or other actions if the value of a property reaches a certain threshold.


As described in 14.6 the pure logging facility provided by the Global Diagnostic Unit does not influence the behavior of the system.

In contrast if the soft- or firmware of a receiver of property values installs a property handler which implements corrective actions, then the faulty measurement or transmission of a property value will lead to the faulty execution of actions specified in this handler.

The consequences depend on the actions of the handler. To prevent that the fault propagates to other parts of the system, it is recommended that the actions of the handler only act on the component for which the handler was installed (the component specified by the compID parameter of PropertyReceiver.registerHandler).


It is necessary to keep a list of all health properties of all components in the system. This information is part of the configuration of the whole system.


30.09.2010 ACROSS Page 104 of 127

16 OPT14: Virtual CAN service [TU Vienna]


During the past decades, the special requirements of different hard and soft real–time applications lead to a fragmentation of real–time networks into many different protocols and standards. Each respective application area has its own highly specialized solutions. For instance, the automotive industry uses serial protocols like CAN, LIN, FlexRay, in automation buses like PROFIBUS and ASi are deployed, and in airplanes AFDX and ARINC 429 are implemented. In order to facilitate the entry of a new technology into the market, the ability to communicate with legacy networks is of highly importance.

The virtual CAN service supports the integration of CAN legacy code in the MPSoC, and the interconnection of the MPSoC to legacy CAN networks.

• R 2.6.1 (Standard Communication Protocols)

16.2 Syntax

interface VirtualCANService { enum CAN_return_code { CAN_TX_ERROR,

CAN_RX_QUEUE_EMPTY, CAN_RECEIVE_BUFFER_OLD,

CAN_PARA_ERROR,

CAN_RX_QUEUE_ERROR,

CAN_TX_ERROR,

}; struct CAN_Link_t { UINT16 id,

}; struct CAN_key_t { UINT16 key, }; struct CAN_Filter_Mode_t { UINT16 mode,

}; struct CAN_Msg_Buffer_t UINT16 buffer,

}; struct CAN_BufferHandle_t UINT16 handle,

}; struct CAN_QueueHandle_t UINT16 queue,


30.09.2010 ACROSS Page 105 of 127

}; struct CAN_msg_t { UINT32 id; UINT8 len;

UINT8 data[8];

};

void CAN_Link_Initalize (in CAN_Link_t link, out CAN_key_t buffer_key); int CAN_AssignRxQueueFilter (in CAN_Link_t *link, in QueueHandle_t que_hdl, in CAN_Filter_Mode_t filter_mode, in UINT32 id, in UINT32 mask); int CAN_ConfigBuffer (in CAN_Link_t *link, in CAN_Msg_Buffer_t type, in UINT32 id, in CAN_BufferHandle_t buf_hdl);

int CAN_ReadQueueStatus (in CAN_Link_t *link, in CAN_QueueHandle_t que_hdl); int CAN_ReadQueueMsg ( in CAN_Link_t *link, in CAN_QueueHandle_t que_hdl, out CAN_Msg_t *msg); int CAN_ReadBufferStatus ( in CAN_Link_t *link, in CAN_BufferHandle_t buf_hdl); int CAN_ReadBufferData ( in CAN_Link_t *link, in CAN_BufferHandle_t buf_hdl, out UINT8 *data_p, out UINT8 *len_p);

int CAN_UpdateBufferData ( in CAN_Link_t *link, in CAN_BufferHandle_t buf_hdl, in UINT8 *data_p, in UINT8 len); int CAN_TransmitMsg ( in CAN_Link_t *link, in CAN_Msg_t *msg); int CAN_RequestMsg ( in CAN_Link_t *link, in UINT32 id);

};

16.3 Protocol

A CAN link has to be initialized with the calls described in 16.5.4.1 and configured with the calls described in 16.5.4.2 before it can be used.


Core services for sporadic and state message transport.

16.5 Description

The virtual CAN service provides virtual CAN channels on top of the TTNoC. Error! Reference source not found. depicts a possible configuration of an ACROSS MPSoC within a CAN network. The blue line illustrates a multicast channel that origins from a remote source and transparently transfers to several cores on the MPSoC and to external devices connected to a physical CAN network. The red channel shows a transfer in the other direction. The CAN gateway enables the transparent forwarding of messages from a virtual CAN channel to a physical CAN line and vice-verse. In both cases the messages are queued within the gateway component, but with different goals:


30.09.2010 ACROSS Page 106 of 127

• event-triggered to time-triggered queue: messages are waiting for the next possible forward instant on the TTNoC

• time-triggered to event-triggered queue: messages are waiting until their priority is accepted by the CAN arbitration mechanism

In order to support a wide variety of legacy CAN applications the virtual CAN gateway service supports the BasicCAN (receive queues) and the FullCAN (mailboxes) behavior. BasicCAN and FullCAN are not defined in the specification of the CAN standard, but describe two different principles in the architecture of a physical CAN controller, considering mainly the way how incoming messages are filtered. BasicCAN is usually used in cheaper standalone CAN controllers or in smaller microcontrollers with an integrated CAN controller. A BasicCAN controller has a single FIFO receive-queue with a global acceptance filter. FullCAN is used in high performance CAN controllers and microcontrollers. FullCAN controllers have a set of buffers called mailboxes that are assigned an identifier and are set to work as transmit, receive or remote buffers. When the CAN controller receives a data message it checks the mailboxes in order to see whether there is a mailbox configured as a receive buffer that has the same identifier as the incoming message. If such a mailbox exists, the message is stored in the mailbox and the host is notified. Otherwise the message is discarded. When a remote message is received the controller checks the message identifier against the mailboxes configured as remote buffers. If a match is found, the controller automatically sends a message with the identifier and data contained in that mailbox.

ACROSS MPSoC

Time-Triggered Network-on-Chip

TRM App. Core App. CoreCAN

Gateway

App. Core App. Core App. Core I/O component

CAN device

CAN device

CAN device

CAN device

Off-Chip CAN Network

TTNoCHostCAN Channel

Legend

Figure 5: Transparent CAN channels via the ACROSS MPSoC Gateway Service

These two operation modes are not restricted to be used exclusively, but can be combined with each other within an application job. Furthermore the virtual CAN gateway service is highly configurable with respect to the number and the length of receive queues and the number of mailboxes. Easy relocation of jobs between components is supported without the need to modify the application code, since the user-visible functions of the API do not contain parameters reflecting a job’s location.

16.5.1 Receive Queues (BasicCAN) Receive queues are recommended for applications where jobs exchange messages with event-semantics, and where jobs are not able to react directly to message-reception. The CAN application middleware supports a configurable number of FIFO receive-queues of configurable length, only limited by the available memory and the available processing time required for serving the queues. Each receive queue is equipped with a dedicated acceptance filter.


30.09.2010 ACROSS Page 107 of 127

Acceptance Filter:

The acceptance filter of a receive-queue can be parameterized by two variables. The variable acceptance_id holds the identifier that should be accepted by the filter, and the variable acceptance_mask declares which bits of the acceptance_id are significant. Whenever the following condition holds, a message is accepted:

(message_id AND acceptance_mask) == (acceptance_id AND acceptance_mask)

By means of these two variables a filter window of variable size can be established. The use of several-receive queues with dedicated filters supports pre-sorting of messages by the application middleware.

Overflows:

Whenever a new message is accepted by the filter of a given receive-queue, and the considered queue is full, an overflow condition occurs. The incoming message will be discarded, and the whole queue will be marked by an overflow flag. Furthermore, a dedicated bit indicating the overflow condition will be set in the last (the newest) message of the queue. A subsequent read-request to the considered queue will indicate that an overflow has occurred since the previous read request. If the user wants to know exactly after which message the overflow has occurred he can examine the overflow indication bit of every message in the queue.

16.5.2 Message Buffers (FullCAN) Message buffers (Mailboxes) are recommended for applications where jobs exchange message with state-semantics. Unlike receive-queues message buffers do not employ FIFO policy. Whenever a new value is put into a message buffer the old value is overwritten with the new value. The CAN application middleware supports a configurable number of message buffers, only limited by the available system resources. Each message buffer is assigned a message identifier and is set to function as a receive buffer, a transmit buffer, or a remote buffer.

Receive Buffers:

Each receive buffer is assigned a message identifier. Whenever a message with a matching identifier is received, it is stored. New messages will overwrite the previous buffer content. A read access to a receive buffer will return the content of the buffer, and the number of updates since the previous read access. This feature gives the user the possibility to see whether the data in the buffer is new and how many updates he has missed.

Transmit Buffers:

Transmit buffers are used to transmit messages. In a first step message data and the message identifier have to be placed into a transmit buffer. In a subsequent step the buffer can be marked for transmission. Transmit buffers implement the information push behavior [Deline, 1999], since data and control flow have the same orientation, i.e. the information transfer occurs via the sender’s request.

Remote Buffers:

Remote buffers support the feature of processing CAN remote-requests automatically. Every remote buffer is assigned a message identifier. Whenever a remote-request message is received all remote buffers are checked. If the identifier of a remote buffer matches the identifier of the remote-request message, the application middleware automatically sends a message with the identifier and the data contained in that buffer. Remote buffers implement the information pull behavior [Deline, 1999] since information transfer is initiated via the receiver’s request and data and control flow have complementary orientations.


30.09.2010 ACROSS Page 108 of 127

16.5.3 Data structures CAN_Msg_t CAN messages are represented in data structures of the type CAN_msg_t.

CAN_Msg_t Description

Id 11/29 bit identifier of the CAN message (right justified) bit 31: frame format (standard or extended) bit 32: frame type (data or remote)

Len Data Length Code

Data data the user wants to transmit

The member id stores the identifier of the CAN message. Two frame formats are supported: In the Standard Frame Format an 11 bit long identifier is used, in the Extended Frame Format the identifier is 29 bit long. The identifier is always right justified. Bit 31 of the member id indicates the frame format (‘0’=Standard Frame Format; ‘1’=Extended Frame Format). Bit 32 of the member id indicates the frame type (‘0’=Data Frame; ‘1’=Remote Frame).

The member len holds the Data Length Code. It indicates how many bytes of the array data contain valid data (Valid Range: 0 – 8).

CAN_Link_t A CAN application is attached to a virtual CAN network by means of a CAN link which is referenced by a handle of type CAN_Link_t. A link handle that corresponds to a given virtual network can be obtained with the function CAN_Link_Initialize. If an application should be attached to multiple virtual CAN networks, a dedicated link handle has to be obtained for each virtual network. QueHandle_t A CAN link can have multiple receive queues. Within a link each receive queue is identified by a handle of type QueueHandle_t. BufferHandle_t

A CAN link can have multiple message buffers (remote and receive buffers). Within a link each message buffer is identified by a handle of type BufferHandle_t.

16.5.4 API Calls 16.5.4.1 Initialization CAN_Link_Initialize Description: Generates a link handle, and binds that handle to a CAN link (The CAN link is provided

by the CAN middleware task). Parameter: can_link_p (out) The handle that is attached to the CAN link

sharedbuffer_key (in) Identifier of the shared memory region where the data structures of the CAN link are

located. Return Value: No return value.


30.09.2010 ACROSS Page 109 of 127

16.5.4.2 Queue and Buffer Configuration CAN_AssignRxQueueFilter Description: Assignment / blocking of messages to a receive queue. The filter of a receive-queue

can be configured by two parameters. The parameter id holds the identifier that should pass the filter, and the parameter mask declares which bits of the id are significant. Whenever the following condition holds, a message passes the filter: (id AND mask) == (id AND mask) By means of these two parameters a filter window of variable size can be established. The parameter filter_mode defines whether the filter works in the assignment mode or in the blocking mode. In the assignment mode, only the messages that pass the filter are accepted, while all other messages are rejected. In the blocking mode every message that passes the filter is rejected, and only the messages that do not pass the filter are accepted.

Parameter: link (in) Handle of the CAN-link

que_hdl (in) Queue-handle: Identifies uniquely the queue within a link filter_mode (in) “ACCEPT FILTER” Filter works in assignment mode

“REJECT FILTER” Filter works in blocking mode id (in) Identifier of message(s) that should pass the filter mask (in) Filter mask

Return Value: CAN Return Codes CAN_ConfigBuffer Description: Configures a message buffer. A message buffer can be configured to be a Receive

Buffer or a Remote Buffer. In both cases the buffer is assigned an identifier. Parameter: link (in) Handle of the CAN-link

type (in) “RECEIVE BUFFER” Buffer acts as a Receive Buffer “REMOTE BUFFER” Buffer acts as a Remote Buffer

id (in) Message identifier buf_hdl (in) Buffer handle: Identifies uniquely the message buffer within a link

Return Value: CAN Return Codes

16.5.4.3 Receive Functions CAN_ReadQueueStatus Description: Reading the status of a queue. This function delivers the number of unread messages

in the queue, and indicates whether an overflow has occurred. Parameter: link (in) Handle of the CAN-link

que_hdl (in) Queue-handle: Identifies uniquely the queue within a link Return Value: >0 Number of messages in the queue

=0 Queue Empty (CAN_RX_QUEUE_EMPTY) <0 CAN Return Codes

CAN_ReadQueueMsg Description: Gets the next unread message of a queue according to the FIFO principle. Reading of

a message of a receive queue is a consuming action (i.e. the message is removed of the queue after it has been read.)


30.09.2010 ACROSS Page 110 of 127


que_hdl (in) Queue-handle: Identifies uniquely the queue within a link msg (out) Data structure to which the message is copied

Return Value: 1 A message was read (CAN_OK)

=0 Queue Empty (CAN_RX_QUEUE_EMPTY) <0 CAN Return Codes

CAN_ReadBufferStatus Description: Reading the status of a buffer. This functions delivers the number of receive events

since the buffer was last read. Since a message in a message buffer is overwritten by a newly received message (a message buffer can hold only a single message) this value indicates how many messages have been missed by the application.


buf_hdl (in) Buffer handle: Identifies uniquely the message buffer within a link

Return Value: >=0 Number of receive events since the buffer was last read <0 CAN Return Codes

CAN_ReadBufferData Description: Gets the data part of a message in a message buffer. Reading of a message of a

message buffer is not a consuming action (i.e. the message will not be removed of the buffer after it has been read.)


buf_hdl (in) Buffer handle: Identifies uniquely the message buffer within a link data_p (out) Data structure to which the data part of the message will be written

Len_p (out) Data Length Code (i.e. number of bytes that should be interpreted in data_p.) Return Value: CAN Return Codes 16.5.4.4 Transmit Functions CAN_UpdateBufferData Description: Updates the contents of Remote Buffer. This function updates the data field and the

Data Length Code of a message in a Remote Buffer. The id of the message in the buffer can be set by the CAN_ConfigBuffer function.


buf_hdl (in) Buffer handle: Identifies uniquely the message buffer within a link data_p (in) Data field of the message len (in) Data Length Code (i.e. number of bytes that should be interpreted in

data_p.) Return Value: CAN Return Codes

CAN_TransmitMsg Description: Writes a CAN message (Data Frame) to the Transmit Queue of a CAN link


30.09.2010 ACROSS Page 111 of 127

Parameter: link (in) Handle of the CAN-link msg (in) CAN message

Return Value: CAN Return Codes CAN_RequestMsg Description: Writes a Remote Frame to the Transmit Queue of a CAN link. Parameter: link (in) Handle of the CAN-link

id (in) Identifier of the message that is requested by the Remote Frame Return Value: CAN Return Codes Error Code Meaning

CAN_OK Operation successful

CAN_RX_QUEUE_EMPTY Receive queue empty

CAN_RECEIVE_BUFFER_OLD No update since the last read request

CAN_PARA_ERROR Invalid function parameters

CAN_RX_QUEUE_ERROR Overflow of the receive queue

CAN_TX_ERROR Overflow of the transmit queue


Event-triggered/Time-triggered Transfers

• Queue overflows are detected by the service and forwarded to the diagnostic unit


The configuration of the Virtual CAN Service encompasses the configuration of the gateway component governing the physical CAN controllers to send and receive messages from external CAN networks and the configuration for the virtual network layered on top of the TTNoC. The virtual CAN network in the MPSoC provides components with virtual links that are attached to respective CAN lines.

16.7.1 Service configuration • Parameters required for initializing a CAN link (e.g., id of CAN network)

• Queue and Buffer sizes at each component


30.09.2010 ACROSS Page 112 of 127


• TTNoC Ports in order to connect components using the Virtual CAN Service

• Mapping of the wiring structure of a bus-based CAN system to the TTNoC


• Physical CAN Controllers interacting with the off-chip CAN network

• If applicable, remote CAN nodes in external networks


30.09.2010 ACROSS Page 113 of 127

17 OPT15: I/O Service [TTT]


The IO service enables the interaction with the off-chip system in case of event-triggered communication, sensors and actuators. Additionally the control of the off-chip time-triggered communication is also located here.

To be able to integrate multiple SoCs with mixed criticality levels into a single system, the IO service will provide encapsulation mechanisms for containing faults in one SoC for preventing the propagation of faults to other subsystems.

• R 2.1.6 (Encapsulation) • R 2.1.8 (Timeliness for end-to-end communication) • R 2.1.9 (Support for Reliable Off-Chip Transport) • R 2.6.1 (Standard Communication Protocols)

17.2 Syntax

The data access functions follow all the same naming and signature convention : io_<read|write>_<io_type> ( io_Id_Type id

, <user data> *data

[, io_Signal_Status *status]

)

The status will be a one data type for all kinds of signals. Different kinds of I/O will support different sets of status flags dependent on their capabilities. To send the data to TISS, the write operations have to be terminated by io_write_to_TISS ()

To receive all data from TISS, before receiving any data, the following function has to be called: io_read_from_TISS ()

If consistency between signals is not required, the synchronizing functions may be empty. Otherwise additional RAM is required to (temporarily) store the TISS frames.

The same API convention will be used for Ethernet traffic with one exception. As for Ethernet only complete frames will be transferred, the io_write_to_TISS and io_read_from_TISS functions are not needed here.

Another important function will be the initialization at startup time: io_init (*config)

where config is a pointer to the configuration data structure. This parameter may be removed in


30.09.2010 ACROSS Page 114 of 127

the design phase if not necessary.

17.3 Protocol

The user of IO_Service must call io_init ()before the first call to any other service call. Constraints:

The user of IO_Service must call io_read_from_TISS ()before a read command may be called. The user of IO_Service must call io_write_to_TISS () after the last write call.


Core services for sporadic and state message transport.

17.5 Description

TNA

TISS driver

TISS driver

IO Service

Gate-way

Service

TTP Subsystem TTP

TTEthernet

I/O

Eth/TTE Subsystem

IO Subsystem

Application

Figure 17-1. Architecture of the I/O service

In Figure Figure 17-1, the architecture of the I/O service is sketched. The I/O service provides the API for the functionality performed in the integrated I/O and gateway node. The I/O services comprides the modules “IO Service”, “IO Subsystem”, and parts of “TTP Subsystem and Eth/TTE Subsystem” as shown in the figure.

The IO service enables the the interaction with the off-chip system in case of event-triggered communication, sensors and actuators. Additionally the control of the off-chip time-triggered communication is also located here.


30.09.2010 ACROSS Page 115 of 127

It offers the following features to the application:

• Access to various standard I/O devices that are part of the chip or closely attached (e.g., over SPI)

• Configurable I/O configuration per node • Provides a common interface for all I/O signal types • Distributed I/O control which allows to simulatanoiusly use I/O connections on different nodes

(statically assigned at configuration time). Note: Any I/O signal is only assigned to one specific node, they can not be shared.

• Enable Ethernet access • Allows monitoring and control for TTEthernet and TTP off-chip network

To achieve these features we will provide an I/O node that will access the designated I/O devices and transfer their sensor values and status in a time-triggered manner to a port. On the other side it will take the actuator signal values in a time-triggered manner from one or more ports and sends them to the I/O devices.

On the application nodes an I/O layer will provide a consistent API on top of the TISS which hides the communication scheme and provides data and status adaption between the internal representation on TTNoC and the API.

A network management for TTP and TTEthernet allows the maintenance of the off-chip network as well as status provision and controlling their behavior.

17.5.1 Status values Data types: io_Signal_Status (16 bit signed)

This status contains the following bits:

Status bit Meaning

IO_SIGNAL_VALID The value of the signal is available but may be out of date IO_SIGNAL_TISS_NOT_AVAILABLE Signal could not be retrieved from TISS. IO_SIGNAL_NOT_AVAILABLE Signal is not provided by the hardware. In case of CAN the

bus is dead, in case of SPI or other serial interfaces the signal could not read from these interfaces. In case of internal hardware devices the devices reported an error.

IO_SIGNAL_FRESH The value of the signal is up to date and was updated since the last read of the signal. If this flas is set, the IO_SIGNAL_VALID is also set.

IO_SIGNAL_STUCK_AT_HIGH

The signal has a stuck-at failure (only supported for certain devices)

IO_SIGNAL_STUCK_AT_LOW The signal has a stuck-at failure (only supported for certain devices)

Note: Multiple of these flags may be set together.

Note: For ACROSS it may be an option to combine all error status flags to only one (IO_SIGNAL_NOT_AVAILABLE)


30.09.2010 ACROSS Page 116 of 127

Note: The flag IO_SIGNAL_VALID has to be the uppermost bit because then it is possible to check for validity by checking for a negative value. Example: if (status < 0) { do something with the value; }

else {error handling;}

Therefore we can provide a performant macro that returns True if the signal is valid.

#define IS_SIGNAL_VALID(status) ((status) < 0)

#define IS_SIGNAL_FRESH(status) ((io_Signal_Status)(status) == (io_Signal_Status)(IO_SIGNAL_FRESH | IO_SIGNAL_VALID))

17.5.2 Digital IO IO_Type: digital

Data types: io_Digital_Value (8bit signed)

Value range: IO_DIGI_LOW

IO_DIGI_HIGH

IO_DIGI_TRISTATE

API: io_read_digital (io_Id_Type id, io_Digital_Value *data , io_Signal_Status *status]);

io_write_digital (io_Id_Type id, const io_Digital_Value *data);

17.5.3 Analog IO IO_Type: analog

Data types: io_Analog_Value (16bit unsigned)

Value range: 0 - 65535

The value range depends on the capabilities of the I/O hardware. Example: If the HW provides 12 bit data, the value range will be from 0 – 4095.

API: io_read_analog (io_Id_Type id, io_Analog_Value *data , io_Signal_Status *status]);

io_write_analog (io_Id_Type id, const io_Analog_Value *data);

17.5.4 PWM IO IO_Type: pwm

Data types: io_PWM_Value (16bit unsigned)

Value range: 0 - 10000

The value represents a percentage with a granularity of 0.01%. A value of 0 resp. 100% may result in special behavior dependent on the hardware capabilities. This will be decided in the implementation phase and may differ between the demonstrators if they use PWM units that are connected over SPI.


30.09.2010 ACROSS Page 117 of 127

API: io_read_pwm (io_Id_Type id, io_PWM_Value *data , io_Signal_Status *status]);

io_write_pwm (io_Id_Type id, const io_PWM_Value *data);

17.5.5 Communication Control for TTP Data type: io_TTP_Status (16bit unsigned)


Status flag Meaning

TTP_RUNNING TTP is running and synchronized TTP_STARTING_UP TTP is starting up TTP_OFF This flag is always set if the TTP controller is currently in

FREEZE state (switched off). As we use the extension layer this will only be the case if the controller was switched off intentionally.

TTP_ERROR TTP controller has detected a protocol error. Note: Frame errors are not recorded here, only protocol errors (e.g., BIST, SE, CB, AF). Design note: As we will use the extension layer which enables TTP again, this state will be set together with RUNNING, STARTING_UP or OFF because the extension layer will restart the controller after a protocol error autonomously. As the sender does not know when the status is evaluated it will provide an error counter and the last error structure. The receiver node then sets this flag if the error counter increased since the last request.

TTP_SYNCHRONOUS This flag is set if TTP runs synchronous with TTNoC within the configured boundary. The value of this flag is only valid if the flag TTP_RUNNING is set.


Other status bits will be defined in the implementation phase if necessary.

Data type: io_TTP_Command (32bit unsigned)


Command Meaning

TTP_CMD_SWITCH_ON Switch the TTP controller on. It may take several time to put the network to TTP_RUNNING state. Inbetween the network will be in state TTP_STARTING_UP.

TTP_CMD_SWITCH_OFF Switch the TTP controller off. TTP_CMD_SYNCHRONIZATION_ON Switch the synchronization between TTP and TTNoC on. The

limitations and direction of synchronization is part of the configuration of the IO node. It may take several time until the synchronization is established.

TTP_CMD_SYNCHRONIZATION_OFF Switch the synchronization between TTP and TTNoC off. It may take several time until the synchronization between the networks is lost as they may drift slowly.


30.09.2010 ACROSS Page 118 of 127

Note: Multiple of these flags may be set together, although not meaningful in some cases. As the command is one-by-one passed to the IO node, there is the need to provide 2 flags for the same state (one to switch it ON and one to switch it OFF), because it is also necessary to be able to indicate that nothing shall be changed. On the IO node it is easy to detect commands (state changes) because only ‘1’ bits need to be detected. In case that both flags (ON and OFF) are set together it will be defined that the OFF will always win.


Data type: io_TTP_Error (struct containing the error pattern, the network state where it happened). This data is taken directly from the TTP driver.

API: io_read_ttp_status (io_TTP_Status *status);

io_write_ttp_command (io_TTP_Command cmd);

io_read_ttp_last_error (io_TTP_Error *error);

17.5.6 Communication Control for TTEthernet Data type: io_TTE_Status (16bit unsigned)


Status flag Meaning

TTE_RUNNING TTEthernet endsystem is running and synchronized TTE_STARTING_UP TTEthernet endsystem is starting up TTE_OFF TTEthernet endsystem is switched off TTE_ERROR TTEthernet endsystem has detected a protocol error. TTE_SYNCHRONOUS This flag is set if TTEthernet runs synchronous with TTNoC

within the configured boundary. The value of this flag is only valid if the flag TTE_RUNNING is set.



Data type: io_TTE_Command (32bit unsigned)


Command Meaning

TTE_CMD_SWITCH_ON Switch the TTE endsystem on. It may take several time to put the network to TTE_RUNNING state. Inbetween the network will be in state TTE_STARTING_UP.

TTE_CMD_SWITCH_OFF Switch the TTE endsystem off. TTE_CMD_SYNCHRONIZATION_ON Switch the synchronization between TTEthernet and TTNoC

on. The limitations and direction of synchronization is part of the configuration of the IO node. It may take several time until the synchronization is established.

TTE_CMD_SYNCHRONIZATION_OFF Switch the synchronization between TTEthernet and TTNoC


30.09.2010 ACROSS Page 119 of 127

off. It may take several time until the synchronization between the networks is lost as they may drift slowly.



Data type: io_TTE_Error (struct containing the error pattern, and the network state where it happened).

API: io_read_tte_status (io_TTE_Status *status);

io_write_tte_command (io_TTE_Command cmd);

io_read_tte_last_error (io_TTE_Error *error);

17.5.7 Communication Control for Ethernet

Data type: io_Eth_Status (16bit unsigned)


Status flag Meaning

ETH_ERROR Ethernet subsystem has detected an error. t.b.d. in the design phase



Data type: io_Eth_Command (32bit unsigned)


Command Meaning

t.b.d. in the design phase



Data type: io_Eth_Error (struct containing the error information).

API: io_read_eth_status (io_Eth_Status *status);


30.09.2010 ACROSS Page 120 of 127

io_write_eth_command (io_Eth_Command cmd);

io_read_eth_last_error (io_Eth_Error *error);

17.5.8 Data transfer for Ethernet Ethernet traffic is transferred as background traffic over TTEthernet.

Data types: io_Eth_Frame (32bit unsigned , length of ETHER_FRAME_SIZE elements), contains one full Ethernet frame

API: BOOL io_read_eth (io_Id_Type id, io_Eth_Frame data);

BOOL io_write_eth (io_Id_Type id, const io_Eth_Frame data);

The io_read_eth function retrieves the next Ethernet frame from the TISS receive queue. If a frame was received, the function returns True. False indicates an empty receive queue.

The io_write_eth function writes an Ethernet frame to the TISS transmit queue. If the frame could be placed into the queue, the function returns True. False indicates a full transmit queue.


Time-triggered/Time-triggered Transfers

Signal errors are reported by the status which is provided together with each signal.

Missing signal status due to unavailable TTNoC is reported by the status which is provided together with each signal

Time-triggered/Time-triggered Networks

Network errors> are reported by the network management functions for TTP and TTEthernet.

Missing network status due to unavailable TTNoC is reported by the network management functions.

These errors can be forwarded to the diagnostic component


17.7.1 Service configuration Object IO_Signal_Type (models a physical type of a signal, e.g. PWM)

• SignalTypeName • StatusSize

Object IO_Signal (models an I/O signal)

• SignalName • SignalSize • SignalPeriod • Direction • SignalType (reference to an IO_Signal_Type)


30.09.2010 ACROSS Page 121 of 127

17.7.2 Resource configuration 17.7.2.1 Trusted Resource Manager Required ports and channels on the TTNoC

17.7.2.2 Additional resources Object Network_Management (models the network management capabilities of an off-chip network)

• ProvideStatus • ProvideControl

Object Network_Control (models the network management capabilities of an off-chip network)

• TTP_NetworkManagement (reference to a Network_Manangement) • TTE_NetworkManagement (reference to a Network_Manangement) • ETH_NetworkManagement (reference to a Network_Manangement)


30.09.2010 ACROSS Page 122 of 127

18 OPT16: Mass Storage Service


The use of mass storage in the automotive domain application demonstrator will be used for two major purposes:

• Logging Data to the Mass Storage Media, and

• Reading and writing controller-parameters

Data to be logged may be process in- and outputs to analyze and identify the according systems offline with appropriate identification tools or to record reference values for verification, validation and benchmarking.

Also, for logging purposes, a global and unique notion of time must be used. E.g. when logging parameters from two different cores at the “same” time, it must be possible to reconstruct the exact order of events within the ACROSS MPSoC during record-time (this means that timestamps must be saved in addition to the logged data itself).

Typical data to log will be TTNoC-Communication as well as data from inside different application-cores.

Covered Requirements:

• R4.1.2 (Control Approaches)

• R4.1.5 (Verification of Control-Algorithms)

• R4.1.6 (Benchmarking of Results)

18.2 Syntax

interface MassStorage { typedef unsigned long pointer; typedef unsigned long log_id; enum return_code_t { action_ok,

file_not_found, no_permissions,

memory_full,

timeout_while_action

};

enum log_behavior_t { ignore_silent,

ignore_retry,

ignore_error,


30.09.2010 ACROSS Page 123 of 127

critical_error

};

return_code_t MassStorage_Write (in pointer file, in pointer data, out unsigned long bytes_written) return_code_t MassStorage_Read (in pointer file, out pointer buffer, out unsigned long bytes_read)

return_code_t log_id MassStorage_SetupLog (in log_behavior_t Log_Behavior, in pointer LogValue)

return_code_t MassStorage_WriteLog (in any LogValue, in log_id ID)

};

18.3 Protocol

Basic MassStorage – Operations are MassStorage_Write and MassStorage_Read. Based on those IO-Operations, the Logging functionality (MassStorage_SetupLog and MassStorage_WriteLog) is realized.

Logging functions relate to dynamic logging only (when logging statically, log-setup is done during configuration phase). Once MassStorage_SetupLog is called, different values can be logged using MassStorage_WriteLog.

When logging to a destination, in addition to the value to be logged, also the global time of the log-event must be captured by the service and saved into the log-file.


• [ADS2] Persistent Parameter Service

• [OPT8] Operating System Service

18.5 Description

• Static Logging: Means that during configuration everything is set up, during runtime, nothing must be executed separately

• Dynamic logging (recording dedicated values): Means that no predefined logging-action takes place. Instead, the code is instrumented with a Log-function, which defines the logging-action


• In case of an error during logging (e.g. memory full, memory not accessible, memory busy), a predefined reaction has to happen, this could be


30.09.2010 ACROSS Page 124 of 127

o Ignore, retry

o In case of full memory: overwrite oldest value ( ring-buffer)

o Stop logging from now on, throw exception

o


18.7.1 Service configuration • Target destinations of data to be stored (eg: SD/CF-Card, network-share, persistent memory

+ according filenames)

• Naming for storage-files (name + increasing number or date)

• The maximum size of storage-files (in kBytes, or unlimited)

• Behavior in case: “out of memory” (use as ring-buffer, stop recording silent, ignore (retry), stop logging from now on to reset)

• Behaviour in case: “memory not accessible”

• List of signals to be saved (including resolution and save-frequency)

• Log-Frequencies for respective signals

• Definition of triggers (eg. if (Sig1 =,<,>,… VAL) then Start /Stop Logging)


• Ports and channels required to communicate with the storage component



30.09.2010 ACROSS Page 125 of 127

19 Annex: Additional Requirements to D2.1

The ACROSS platform shall support standard communication protocols for the Interconnection of ACCROSS MPSoCs. Candidates are Ethernet or Time-Triggered Ethernet.

R 2.6.1 (S tandard Communica tion Pro tocols )

Significance: Mandatory Rationale: The support of standard protocols facilitates the migration to a novel architecture. Originator: TU Vienna Responsibility: TU Vienna Requirement Status: accepted Requirement Source: system-level requirement – R1.1.2

The execution of precompiled code should be supported by the operating system. R 2.6.2 (Execution of Precompiled Code)

Significance: Mandatory Rationale: The capability to execute pre-compiled code is required to protect the IP of

software modules provided by third party suppliers. Originator: TU Vienna Responsibility: SYSGO Requirement Status: accepted Requirement Source: system-level requirement – R1.1.4

The usage of the optional services should not require the disclosure of the source code of an application. Remark: Nevertheless the availability of the source code can be beneficial for the usage of some services (e.g., debugging services).

R 2.6.3 (Optiona l Services Support IP Pro tec tion)

Significance: Mandatory Rationale: This is required support IP protection of third party suppliers. Originator: TU Vienna Responsibility: All WP2 partners Requirement Status: accepted Requirement Source: system-level requirement – R1.1.4

The optional services are domain-independent and support all targeted application domains. R 2.6.4 (Domain Independence)

Significance: Mandatory Rationale: Domain-specific services are handled in WP4, WP5 and WP6 Originator: TU Vienna Responsibility: All WP2 partners Requirement Status: accepted Requirement Source: system-level requirement – R1.1.7

It should be possible to customize an instance of the ACROSS service by integrating only those optional services that are actually required by the hosted applications.

R 2.6.5 (Flexib ility of the s e t of Optiona l Services )

Significance: Mandatory Rationale: This requirement supports the efficient development and production of products

with different configurations (e.g., customized cars). Furthermore it allows selecting an optional service with an adequate level of reliability for a given application (e.g., fault-tolerance services or different communication services with different levels of reliability).

Originator: TU Vienna


30.09.2010 ACROSS Page 126 of 127

Responsibility: All WP2 partners Requirement Status: accepted Requirement Source: system-level requirement – R1.1.16, R1.2.11

The optional services should provide health information with respect to their operational state (e.g., the voting service should provide information about failed replicas).

R 2.6.6 (Sys tem Health Monitoring)

Significance: Mandatory Rationale: This requirement is an important part for system-wide health monitoring Originator: TU Vienna Responsibility: All WP2 partners Requirement Status: accepted Requirement Source: system-level requirement – R1.4.2, WP5b-PTS-107

Device drivers for legacy networks (e.g., tcp/ip) have to be provided R 2.6.7 (Legacy device drivers )

Significance: Mandatory Rationale: The support of legacy protocols facilitates the migration to a novel architecture. Originator: TU Vienna Responsibility: SYSGO Requirement Status: accepted Requirement Source: system-level requirement – R1.6.2

For a selected set of optional services (e.g., services for safety-critical hard real-time systems) the start-up time has to be bounded.

R 2.6.8 (Bounded Sta rt-Up Time)

Significance: Mandatory Rationale: The support of legacy protocols facilitates the migration to a novel architecture. Originator: TU Vienna Responsibility: All WP2 partners Requirement Status: accepted Requirement Source: system-level requirement – R1.9.2

The secure boot service (R2.2.3) should provide a unique identifier for each loaded application image. R 2.6.9 (Configura tion Reporting)

Significance: Mandatory Rationale: This service is required for determining the actual configuration of a platform. Originator: TU Vienna Responsibility: TU Vienna Requirement Status: accepted Requirement Source: system-level requirement – R1.9.8

The platform should provide a service for generating and checking checksums for the purpose of reliable communication.

R 2.6.10 (Checks ums for Communication)

Significance: Mandatory Rationale: This service can be used by the application for end-to-end checks. Originator: TU Vienna


30.09.2010 ACROSS Page 127 of 127

Responsibility: TU Vienna Requirement Status: accepted Requirement Source: system-level requirement – R1.9.10

Documents

trimis.ec.europa.eu · Table of Contents Document versions