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
Deliverable No. D2.2
Contact Person
Christian El Salloum
Organisation
TU Vienna
Phone
+43 58801 18225
E-Mail
salloum@vmars.tuwien.ac.at
30.09.2010
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 2 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
Table of Contents
Document versions ....................................................................................................................................... 2
1
2
3
4
5
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
Service Specification ............................................................................................................................. 9
2.1
Interfaces of a Service ................................................................................................................... 9
2.2
Service Configuration .................................................................................................................... 9
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
OPT2: Transparent Gateway Service [TTT] ......................................................................................... 12
4.1
Rationale and Covered Requirements ........................................................................................ 12
4.2
Syntax .......................................................................................................................................... 12
4.3
Protocol ....................................................................................................................................... 12
4.4
Dependency on Other Services ................................................................................................... 12
4.5
Description .................................................................................................................................. 12
4.6
Fault Assumptions and Behavior in Presence of Faults .............................................................. 13
4.7
Configuration interface (Interface to WP3) ................................................................................ 14
4.7.1
Service configuration .......................................................................................................... 14
4.7.2
Resource configuration ....................................................................................................... 14
OPT3: Secure Group Communication Service [TU Vienna] ................................................................. 15
5.1
Rationale and Covered Requirements ........................................................................................ 15
5.2
Syntax .......................................................................................................................................... 16
5.3
Protocol ....................................................................................................................................... 17
30.09.2010
ACROSS
Page 3 of 127
Del.No.(D2.2)
6
7
8
Version: 1.0
Confidentiality Level: PU
5.4
Dependency on Other Services ................................................................................................... 17
5.5
Description .................................................................................................................................. 17
5.6
Fault Assumptions and Behavior in Presence of Faults .............................................................. 18
5.7
Configuration interface (Interface to WP3) ................................................................................ 19
5.7.1
Service configuration .......................................................................................................... 19
5.7.2
Resource configuration ....................................................................................................... 19
OPT4: Secure Boot Service [TU Vienna] .............................................................................................. 20
6.1
Rationale and Covered Requirements ........................................................................................ 20
6.2
Syntax .......................................................................................................................................... 20
6.3
Protocol ....................................................................................................................................... 21
6.4
Dependency on Other Services ................................................................................................... 22
6.5
Description .................................................................................................................................. 22
6.6
Fault Assumptions and Behavior in Presence of Faults .............................................................. 23
6.7
Configuration interface (Interface to WP3) ................................................................................ 23
6.7.1
Service configuration .......................................................................................................... 23
6.7.2
Resource configuration ....................................................................................................... 23
OPT5: Voting Service [fortiss] ............................................................................................................. 24
7.1
Rationale and Covered Requirements ........................................................................................ 24
7.2
Syntax .......................................................................................................................................... 25
7.3
Protocol ....................................................................................................................................... 26
7.4
Dependency on Other Services ................................................................................................... 26
7.5
Description .................................................................................................................................. 26
7.6
Fault Assumptions and Behavior in Presence of Faults .............................................................. 27
7.7
Configuration interface (Interface to WP3) ................................................................................ 27
7.7.1
Service configuration .......................................................................................................... 27
7.7.2
Resource configuration ....................................................................................................... 27
OPT6: State Externalization Service [TU Vienna] ................................................................................ 28
8.1
Rationale and Covered Requirements ........................................................................................ 28
8.2
Syntax .......................................................................................................................................... 29
8.3
Protocol ....................................................................................................................................... 29
8.4
Dependency on Other Services ................................................................................................... 29
8.5
Description .................................................................................................................................. 30
8.6
Fault Assumptions and Behavior in Presence of Faults .............................................................. 30
8.7
Configuration interface (Interface to WP3) ................................................................................ 31
8.7.1
30.09.2010
Service configuration .......................................................................................................... 31
ACROSS
Page 4 of 127
Del.No.(D2.2)
8.7.2
9
Version: 1.0
Confidentiality Level: PU
Resource configuration ....................................................................................................... 31
OPT7: State Restoration Service [TU Vienna] ..................................................................................... 32
9.1
Rationale and Covered Requirements ........................................................................................ 32
9.2
Syntax .......................................................................................................................................... 32
9.3
Protocol ....................................................................................................................................... 32
9.4
Dependency on Other Services ................................................................................................... 32
9.5
Description .................................................................................................................................. 33
9.6
Fault Assumptions and Behavior in Presence of Faults .............................................................. 33
9.7
Configuration interface (Interface to WP3) ................................................................................ 33
9.7.1
Service configuration .......................................................................................................... 33
9.7.2
Resource configuration ....................................................................................................... 33
10
OPT8: Operating System Services [SYSGO] ..................................................................................... 34
10.1
Rationale and Covered Requirements ........................................................................................ 34
10.2
Syntax .......................................................................................................................................... 34
10.3
Protocol ....................................................................................................................................... 34
10.4
Dependency on Other Services ................................................................................................... 34
10.5
Description .................................................................................................................................. 34
10.6
Fault Assumptions and Behavior in Presence of Faults .............................................................. 41
10.7
Configuration interface (Interface to WP3) ................................................................................ 41
11
OPT9: BEE Services [ED] .................................................................................................................. 42
11.1
Rationale and Covered Requirements ........................................................................................ 42
11.2
Syntax .......................................................................................................................................... 42
11.3
Protocol ....................................................................................................................................... 67
11.4
Dependency on Other Services ................................................................................................... 72
11.5
Description .................................................................................................................................. 72
11.6
Fault Assumptions and Behavior in Presence of Faults .............................................................. 74
11.7
Configuration interface (Interface to WP3) ................................................................................ 83
12
OPT10: Real-Time Tracing Service [LAUTERBACH] ......................................................................... 90
12.1
Rationale and Covered Requirements ........................................................................................ 90
12.2
Syntax .......................................................................................................................................... 91
12.3
Protocol ....................................................................................................................................... 92
12.4
Dependency on Other Services ................................................................................................... 92
12.5
Description .................................................................................................................................. 93
12.6
Fault Assumptions and Behavior in Presence of Faults .............................................................. 93
12.7
Configuration interface (Interface to WP3) ................................................................................ 93
30.09.2010
ACROSS
Page 5 of 127
Del.No.(D2.2)
13
Version: 1.0
Confidentiality Level: PU
OPT11: Debugging Service [LAUTERBACH] ..................................................................................... 94
13.1
Rationale and Covered Requirements ........................................................................................ 94
13.2
Syntax .......................................................................................................................................... 94
13.3
Protocol ....................................................................................................................................... 95
13.4
Dependency on Other Services ................................................................................................... 96
13.5
Description .................................................................................................................................. 96
13.6
Fault Assumptions and Behavior in Presence of Faults .............................................................. 96
13.7
Configuration interface (Interface to WP3) ................................................................................ 96
14
OPT12: Health Monitoring Service (Local DU) [LAUTERBACH] ....................................................... 97
14.1
Rationale and Covered Requirements ........................................................................................ 97
14.2
Syntax .......................................................................................................................................... 98
14.3
Protocol ....................................................................................................................................... 98
14.4
Dependency on Other Services ................................................................................................... 99
14.5
Description .................................................................................................................................. 99
14.6
Fault Assumptions and Behavior in Presence of Faults .............................................................. 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
15.7
Configuration interface (Interface to WP3) .............................................................................. 103
16
OPT14: Virtual CAN service [TU Vienna] ....................................................................................... 104
16.1
Rationale and Covered Requirements ...................................................................................... 104
16.2
Syntax ........................................................................................................................................ 104
16.3
Protocol ..................................................................................................................................... 105
16.4
Dependency on Other Services ................................................................................................. 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
16.6
Fault Assumptions and Behavior in Presence of Faults ............................................................ 111
30.09.2010
ACROSS
Page 6 of 127
Del.No.(D2.2)
16.7
Version: 1.0
Confidentiality Level: PU
Configuration interface (Interface to WP3) .............................................................................. 111
16.7.1
Service configuration ........................................................................................................ 111
16.7.2
Resource configuration ..................................................................................................... 112
17
OPT15: I/O Service [TTT] ............................................................................................................... 113
17.1
Rationale and Covered Requirements ...................................................................................... 113
17.2
Syntax ........................................................................................................................................ 113
17.3
Protocol ..................................................................................................................................... 114
17.4
Dependency on Other Services ................................................................................................. 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
17.6
Fault Assumptions and Behavior in Presence of Faults ............................................................ 120
17.7
Configuration interface (Interface to WP3) .............................................................................. 120
17.7.1
Service configuration ........................................................................................................ 120
17.7.2
Resource configuration ..................................................................................................... 121
18
OPT16: Mass Storage Service........................................................................................................ 122
18.1
Rationale and Covered Requirements ...................................................................................... 122
18.2
Syntax ........................................................................................................................................ 122
18.3
Protocol ..................................................................................................................................... 123
18.4
Dependency on Other Services ................................................................................................. 123
18.5
Description ................................................................................................................................ 123
18.6
Fault Assumptions and Behavior in Presence of Faults ............................................................ 123
18.7
Configuration interface (Interface to WP3) .............................................................................. 124
19
18.7.1
Service configuration ........................................................................................................ 124
18.7.2
Resource configuration ..................................................................................................... 124
Annex: Additional Requirements to D2.1 ..................................................................................... 125
30.09.2010
ACROSS
Page 7 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 8 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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).
API
behavior
reconfiguration
Service
Message interface
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
configuration
Service
allocates
Resources
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 9 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 10 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 11 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
4 OPT2: Transparent Gateway Service [TTT]
4.1 Rationale and Covered Requirements
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.
4.4 Dependency on Other Services
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 12 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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, offline, 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.
4.6 Fault Assumptions and Behavior in Presence of Faults
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 13 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
4.7 Configuration interface (Interface to WP3)
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)
4.7.2 Resource configuration
4.7.2.1 Trusted Resource Manager
•
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 14 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
5 OPT3: Secure Group Communication Service [TU Vienna]
5.1 Rationale and Covered Requirements
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 15 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 16 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
5.4 Dependency on Other Services
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 17 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
•
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).
5.6 Fault Assumptions and Behavior in Presence of Faults
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)
2)
Insertion attack: A new message is injected in an event-based message channel producing a faked
event.
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 18 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
5.7 Configuration interface (Interface to WP3)
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.
5.7.2 Resource configuration
5.7.2.1 Trusted Resource Manager
•
TTNoC Ports at the sending and receiving components have to be allocated
•
Routing of messages between these ports has to be established
5.7.2.2 Additional resources
•
General configuration of the components executing the security kernel
o e.g., enables MMU to provide memory protection.
30.09.2010
ACROSS
Page 19 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
6 OPT4: Secure Boot Service [TU Vienna]
6.1 Rationale and Covered Requirements
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 20 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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:
011001010001111010
010101111010111001
101011110111010101
011011000101001110
101101110011100012
Job image
operator
Host @ ACROSS MPSoC
1a. deliver
011001010001111010
010101111010111001
101011110111010101
011011000101001110
101101110011100012
Authority 2. sign
Authentication key
Job image
1b. deliver
Checksum
5. start
Host
processor
4. authorize
Verification key
3. verify
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 21 of 127
Del.No.(D2.2)
5.
Version: 1.0
Confidentiality Level: PU
Finally, the host loads the job image in its working memory and executes the job.
6.4 Dependency on Other Services
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
secure boot error code
Return Value:
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:
Return Value:
job (in)
Unique job identifier
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
secure boot error code
Return Value:
Error Code
Meaning
invalid_job_id
The job id does not exist or the format is invalid.
30.09.2010
ACROSS
Page 22 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
6.6 Fault Assumptions and Behavior in Presence of Faults
The assumed intentional faults are:
•
Job image is fake
•
Job image has been corrupted
•
Job image has been replaced
6.7 Configuration interface (Interface to WP3)
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.
6.7.2 Resource configuration
6.7.2.1 Trusted Resource Manager
•
TTNoC Ports in order to load an image from a storage
6.7.2.2 Additional resources
•
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 23 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
7 OPT5: Voting Service [fortiss]
7.1 Rationale and Covered Requirements
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
30.09.2010
ACROSS
Page 24 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 25 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
7.4 Dependency on Other Services
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 26 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
7.6 Fault Assumptions and Behavior in Presence of Faults
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 Configuration interface (Interface to WP3)
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 27 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
8 OPT6: State Externalization Service [TU Vienna]
8.1 Rationale and Covered Requirements
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 28 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
8.4 Dependency on Other Services
This service depends on the core communication services and the core clock synchronization services.
30.09.2010
ACROSS
Page 29 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 port_id
The port is not configured in the TISS.
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).
8.6 Fault Assumptions and Behavior in Presence of Faults
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 30 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
8.7 Configuration interface (Interface to WP3)
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
8.7.2 Resource configuration
8.7.2.1 Trusted Resource Manager
•
TTNoC Ports to disseminate the state
30.09.2010
ACROSS
Page 31 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
9 OPT7: State Restoration Service [TU Vienna]
9.1 Rationale and Covered Requirements
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.
9.4 Dependency on Other Services
This service is closely related to the state externalization service (OPT6)
30.09.2010
ACROSS
Page 32 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 port_id
The port is not configured in the TISS.
invalid_pointer
The pointer is invalid (e.g., NULL pointer, inaccessible
memory area).
9.6 Fault Assumptions and Behavior in Presence of Faults
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.
9.7 Configuration interface (Interface to WP3)
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
9.7.2 Resource configuration
9.7.2.1 Trusted Resource Manager
•
TTNoC Port for restart message
30.09.2010
ACROSS
Page 33 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
10 OPT8: Operating System Services [SYSGO]
10.1 Rationale and Covered Requirements
•
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
10.4 Dependency on Other Services
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 34 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 35 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 36 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 37 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 38 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 Management 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 39 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 diagnostics 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 40 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
10.6 Fault Assumptions and Behavior in Presence of Faults
n/a
10.7 Configuration interface (Interface to WP3)
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 41 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
11 OPT9: BEE Services [ED]
11.1 Rationale and Covered Requirements
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:
Class
Package:
infrastructure
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
Generalization
Public
StatusCondition
Public
Condition
Public
GuardCondition
Public
Condition
Public
ReadCondition
Public
Condition
Source -> Destination
Generalization
Source -> Destination
Generalization
Source -> Destination
Notes
Attributes
Attribute
30.09.2010
Notes
Constraints and tags
ACROSS
Page 42 of 127
Del.No.(D2.2)
Attribute
Version: 1.0
Notes
Confidentiality Level: PU
Constraints and tags
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 43 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
DDSException
Type:
Class Exception
Package:
infrastructure
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.
Connector
Source
Generalization
Public
Public
ResourceLimitExcepti DDSException
on
Source -> Destination
Association
Source -> Destination
Public
DDSException
Target
Notes
Protected type
ErrorType
Attributes
Attribute
Notes
Constraints and tags
serialVersionUID long
Private
Static Const
Default: 1L
type ErrorType
Protected
Default:
30.09.2010
ACROSS
Page 44 of 127
Del.No.(D2.2)
Version: 1.0
Attribute
Notes
Confidentiality Level: PU
Constraints and tags
nestedException
Exception
Protected
Default:
Operations
Method
Notes
Parameters
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
Package:
infrastructure
A GuardCondition object is a specific Condition whose trigger_value is completely under the control of
the application.
Connections
Connector
30.09.2010
Source
Target
ACROSS
Notes
Page 45 of 127
Del.No.(D2.2)
Version: 1.0
Connector
Source
Target
Generalization
Public
GuardCondition
Public
Condition
Source -> Destination
Confidentiality Level: PU
Notes
Operations
Method
Notes
Parameters
setTriggerValue() void
Public
Set the trigger value.
boolean [in] value
QosPolicy
Type:
Class Cloneable, Serializable
Package:
infrastructure
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
Connector
Source
Generalization
Public
Public
ResourceLimitsQosPo QosPolicy
licy
Source -> Destination
Generalization
Source -> Destination
Generalization
Source -> Destination
Generalization
Source -> Destination
30.09.2010
Public
DurabilityQosPolicy
Target
Notes
Public
QosPolicy
Public
Public
TransportPriorityQos QosPolicy
Policy
Public
Public
LatencyBudgetQosPo QosPolicy
licy
ACROSS
Page 46 of 127
Del.No.(D2.2)
Version: 1.0
Connector
Source
Target
Generalization
Public
HistoryQosPolicy
Public
QosPolicy
Source -> Destination
Generalization
Source -> Destination
Generalization
Source -> Destination
Generalization
Source -> Destination
Generalization
Source -> Destination
Generalization
Source -> Destination
Generalization
Source -> Destination
Generalization
Source -> Destination
Generalization
Source -> Destination
Confidentiality Level: PU
Notes
Public
Public
OwnershipStrengthQ QosPolicy
osPolicy
Public
Public
TimeBasedFilterQosP QosPolicy
olicy
Public
PartitionQosPolicy
Public
QosPolicy
Public
OwnershipQosPolicy
Public
QosPolicy
Public
DeadlineQosPolicy
Public
QosPolicy
Public
ReliabilityQosPolicy
Public
QosPolicy
Public
Public
DbTablePersistencyP QosPolicy
olicy
Public
LifespanQosPolicy
Public
QosPolicy
Attributes
Attribute
30.09.2010
Notes
Constraints and tags
ACROSS
Page 47 of 127
Del.No.(D2.2)
Version: 1.0
Attribute
Notes
Confidentiality Level: PU
Constraints and tags
serialVersionUID long
Private
Static Const
Default: 1L
name String
Protected
Default:
Operations
Method
Notes
Parameters
QosPolicy()
Protected
String [in] name
Static search() T
Public
Utility method that returns the desired
List<QosPolicy> [in] qosList
policy from a list, if the policy is not found
null is returned.
Class<T> [in] type
clone() QosPolicy
Public
toString() String
Public
ResourceLimitException
Type:
Class DDSException
Package:
infrastructure
30.09.2010
ACROSS
Page 48 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
Exception thrown when the 'ResourceLimits' qos policy bounds are overtaken on a DataWriter by the
application.
Connections
Connector
Source
Generalization
Public
Public
ResourceLimitExcepti DDSException
on
Source -> Destination
Target
Notes
Attributes
Attribute
Notes
Constraints and tags
serialVersionUID long
Private
Static Const
Default: 1L
Operations
Method
Notes
Parameters
ResourceLimitException
()
Protected
ErrorType [in] type
WaitSet
Type:
Class
Package:
infrastructure
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 49 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
Attributes
Attribute
Notes
Constraints and tags
conditions
List<Condition>
Private
Default:
currentSemaphore
Semaphore
Private
Default:
semaphoreLock Object
Private
Default:
Operations
Method
Notes
Parameters
WaitSet()
Public
attachCondition() void
Public
30.09.2010
Attaches a Condition to the WaitSet. It is
Condition [in] condition
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.
ACROSS
Page 50 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
Method
Notes
Parameters
detachCondition()
boolean
Public
Detaches a Condition from the WaitSet.
Condition [in] condition
waitFor()
List<Condition>
Public
This operation allows an application
long [in] timeout
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.
<p> 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.
getConditions()
List<Condition>
Public
Returns the list of conditions.
Listener
Type:
Interface
Package:
infrastructure
This is the root interface of every entity's listener interface.
Connections
Connector
Source
Target
Generalization
Public
TopicListener
Public
Listener
Public
DataReaderListener
Public
Listener
Source -> Destination
Generalization
Source -> Destination
30.09.2010
ACROSS
Notes
Page 51 of 127
Del.No.(D2.2)
Version: 1.0
Connector
Source
Target
Generalization
Public
DataWriterListener
Public
Listener
Source -> Destination
Confidentiality Level: PU
Notes
DataWriter
Type:
Interface DomainEntity
Package:
publication
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
Connector
Source
Target
Generalization
Public
DataWriter
Public
DomainEntity
Source -> Destination
Notes
Operations
Method
Notes
Parameters
getPublisher() Publisher
Public
getTopic() Topic<T>
Public
registerInstance()
InstanceHandle
Public
30.09.2010
Inform the service the intention to publish T [in] sample
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.
ACROSS
Page 52 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
Method
Notes
Parameters
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.
<p> 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.
<p> 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 T [in] data
instance.
the Data to be written.
InstanceHandle [in] handle
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).
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
30.09.2010
This method write a data sample, the topic T [in] data
instance of the sample is automatically
detected by the system (it's equivalent to
invoke 'write(data, null)').
ACROSS
Page 53 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
Method
Notes
Parameters
writeWithTimestamp()
void
Public
Write a sample using the specified
timestamp, the sample instance is
automatically detected.
T [in] data
waitForAcknowledgme
nts() boolean
Public
Waits the calling thread until all samples in long [in] timeout
the queue are propagated to the
subscriptions.
@return true if the operation releases
until the timeout, otherwise false.
lookupInstance()
InstanceHandle
Public
Returns the instance handle of the sample T [in] sample
passed as parameter, null if the instance is
not already registered.
long [in] timestamp
getPublicationMatched Returns the publication matched status,
Status()
that gives information about the remote
PublicationMatchedStat subscriptions discovered.
us
Public
getOfferedIncompatible
QosStatus()
OfferedIncompatibleQos
Status
Public
Returns the offered incompatible qos
status, that gives information about the
remote subscriptions with incompatible
qos discovered.
getOfferedDeadlineMis
sedStatus()
OfferedDeadlineMissedS
tatus
Public
Returns the offered deadline missed
status, that gives information about the
times that the data samples are not
published like expected.
DataWriterListener
Type:
Interface Listener
Package:
publication
Interface that must be implemented by a datawriter's listener.
30.09.2010
ACROSS
Page 54 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
Connections
Connector
Source
Target
Generalization
Public
DataWriterListener
Public
Listener
Source -> Destination
Realisation
Source -> Destination
Generalization
Source -> Destination
Notes
Public
Public
DataWriterListenerIm DataWriterListener
pl
Public
PublisherListener
Public
DataWriterListener
Operations
Method
Notes
Parameters
onOfferedIncompatible A QosPolicy value was incompatible with
Qos() void
what was requested.
Public
DataWriter<?> [in] writer
OfferedIncompatibleQosStatus
[in] status
onPublicationMatched() The DataWriter has found DataReader
void
that matches the Topic and has
compatible QoS, or has ceased to be
Public
matched with a DataReader that was
previously considered to be matched.
DataWriter<?> [in] writer
onOfferedDeadlineMiss Deadline missed.
ed() void
Public
DataWriter<?> [in] writer
PublicationMatchedStatus [in]
status
OfferedDeadlineMissedStatus [in]
status
DataSample
Type:
30.09.2010
Class
ACROSS
Page 55 of 127
Del.No.(D2.2)
Package:
Version: 1.0
Confidentiality Level: PU
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
Connector
Source
Target
Association
Public
DataSample
Private sampleInfo
SampleInfo
Source -> Destination
Notes
Attributes
Attribute
Notes
Constraints and tags
data T
Private
Default:
sampleInfo SampleInfo
Private
Default:
Operations
Method
Notes
Parameters
DataSample()
Public
T [in] data
SampleInfo [in] info
30.09.2010
ACROSS
Page 56 of 127
Del.No.(D2.2)
Version: 1.0
Method
Notes
getData() T
Public
The data sample.
getSampleInfo()
SampleInfo
Public
The sample info object.
Confidentiality Level: PU
Parameters
QueryCondition
Type:
Class ReadCondition
Package:
subscription
This condition triggers each time that a sample that match the filter expression is received.
Connections
Connector
Source
Target
Generalization
Public
QueryCondition
Public
ReadCondition
Source -> Destination
Notes
Operations
Method
Notes
Parameters
QueryCondition()
Protected
DataReader<?> [in] reader
getQueryExpression()
String
Public
Returns the filter expression.
setQueryExpression()
void
Public
Set the filter expression.
String [in] expression
ReadCondition
Type:
Class Condition
Package:
subscription
30.09.2010
ACROSS
Page 57 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
This condition triggers each time that a sample is received.
Connector
Source
Target
Generalization
Public
ReadCondition
Public
Condition
Public
QueryCondition
Public
ReadCondition
Source -> Destination
Generalization
Source -> Destination
Notes
Attributes
Attribute
Notes
Constraints and tags
reader DataReader<?>
Protected
Default:
Operations
Method
Notes
Parameters
ReadCondition()
Protected
getDataReader()
DataReader<?>
Public
DataReader<?> [in] reader
Returns the data reader which this
condition belongs to.
SampleInfo
Type:
Class
Package:
subscription
30.09.2010
ACROSS
Page 58 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
Class that provides informations about a sample of data.
Connections
Connector
Source
Target
Association
Public
SampleInfo
Private
publicationHandle
InstanceHandle
Public
SampleInfo
Private
instanceHandle
InstanceHandle
Public
DataSample
Private sampleInfo
SampleInfo
Public
SampleInfo
Private
sampleStateKind
SampleStateKind
Source -> Destination
Association
Source -> Destination
Association
Source -> Destination
Association
Source -> Destination
Notes
Attributes
Attribute
Notes
Constraints and tags
sampleStateKind
SampleStateKind
Private
Default:
sourceTimestamp long
Private
Default:
30.09.2010
ACROSS
Page 59 of 127
Del.No.(D2.2)
Attribute
Version: 1.0
Notes
Confidentiality Level: PU
Constraints and tags
instanceHandle
InstanceHandle
Private
Default:
publicationHandle
InstanceHandle
Private
Default:
Operations
Method
Notes
Parameters
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 60 of 127
Del.No.(D2.2)
Version: 1.0
Method
Notes
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.
Confidentiality Level: PU
Parameters
DataReader
Type:
Interface DomainEntity
Package:
subscription
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
Connector
Source
Target
Generalization
Public
DataReader
Public
DomainEntity
Source -> Destination
Notes
Operations
Method
Notes
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
Parameters
ACROSS
Page 61 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
Method
Notes
read()
List<DataSample<T>>
Public
This operation accesses a collection of
int [in] maxSamples
Data values from the DataReader. The size
of the returned collection will be limited
to the specified maxSamples.
<p> The samples are ordered from the
older to the newest ones, first are placed
the already accessed samples, then the
not accessed samples.
readWithCondition()
List<DataSample<T>>
Public
<p> This operation accesses a collection of int [in] maxSamples
Data values from the DataReader. The size
of the returned collection will be limited
ReadCondition [in] condition
to the specified maxSamples.
<p> 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.
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.
<p> 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
readInstance()
List<DataSample<T>>
Public
This operation accesses a collection of
int [in] maxSamples
Data values from the DataReader. The
behavior is identical to read except that all
InstanceHandle [in] handle
samples returned belong to the single
specified instance whose handle is the
parameter handle. Upon successful return,
30.09.2010
Parameters
ACROSS
ReadCondition [in] condition
Page 62 of 127
Del.No.(D2.2)
Method
Version: 1.0
Notes
Confidentiality Level: PU
Parameters
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.
readNextSample()
DataSample<T>
Public
This operation copies the next, nonpreviously 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, nonpreviously 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
int [in] maxSamples
InstanceHandle [in] handle
Page 63 of 127
Del.No.(D2.2)
Version: 1.0
Method
Confidentiality Level: PU
Notes
Parameters
Detach the read condition.
ReadCondition [in] condition
Public
deleteReadCondition()
void
Public
createQueryCondition() Creates a query condition with the
QueryCondition
specified filter expression.
Public
getSampleLostStatus()
SampleLostStatus
Public
String [in] queryExpression
Returns the sample lost status, that gives
information about the samples lost during
the communication with a data writer.
getSubscriptionMatche Returns the subscription matched status,
dStatus()
that gives information about the remote
SubscriptionMatchedSta publication discovered.
tus
Public
getRequestedIncompati
bleQosStatus()
RequestedIncompatible
QosStatus
Public
Returns the requested incompatible
status, that gives information about the
remote publications with incompatible qos
discovered.
getSampleRejectedStat
us()
SampleRejectedStatus
Public
Returns the sample rejected status, that
gives information about the samples
rejected for overtaking the resource limits
bounds.
getRequestedDeadline
MissedStatus()
RequestedDeadlineMiss
edStatus
Public
Returns the requested deadline missed
status, that gives information about the
times that the data samples are not
arrived like expected.
DataReaderListener
Type:
Interface Listener
Package:
subscription
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 64 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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
Connector
Source
Target
Generalization
Public
DataReaderListener
Public
Listener
Public
DataReaderListenerI
mpl
Public
DataReaderListener
Source -> Destination
Realisation
Source -> Destination
Generalization
Source -> Destination
Generalization
Source -> Destination
Notes
Public
Public
UntypedDataReaderL DataReaderListener
istener
Public
Public
TypedDataReaderList DataReaderListener
ener
Operations
Method
Notes
Parameters
onDataAvailable() void
Public
A new sample is available on the data
reader.
DataReader<T> [in] reader
onRequestedIncompati A data reader has received a request by a DataReader<T> [in] reader
bleQos() void
remote publication with incompatible qos.
Public
RequestedIncompatibleQosStatus
[in] status
onSampleLost() void
Public
30.09.2010
A sample is lost during the transmission
for a data reader.
ACROSS
DataReader<T> [in] reader
Page 65 of 127
Del.No.(D2.2)
Version: 1.0
Method
Notes
Confidentiality Level: PU
Parameters
SampleLostStatus [in] status
onSubscriptionMatched A matched publication is found.
() void
Public
DataReader<T> [in] reader
SubscriptionMatchedStatus [in]
status
onSampleRejected()
void
Public
A sample is rejected.
DataReader<T> [in] reader
SampleRejectedStatus [in] status
onRequestedDeadlineM Deadline missed.
issed() void
Public
DataReader<T> [in] reader
RequestedDeadlineMissedStatus
[in] status
TypeSupport
Type:
Class Serializable
Package:
topic
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
Attribute
30.09.2010
Notes
Constraints and tags
ACROSS
Page 66 of 127
Del.No.(D2.2)
Version: 1.0
Attribute
Notes
Confidentiality Level: PU
Constraints and tags
serialVersionUID long
Private
Static Const
Default: 1L
DDSKey
Type:
Interface
Package:
topic
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; } &#64;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 67 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
DataWriter, which immediately informs the Publisher.
30.09.2010
ACROSS
Page 68 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 69 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 70 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 71 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
11.4 Dependency on Other Services
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.
Data
Base
VHF
BEE
VHF
Air Segment
VHF
BEE
VHF
GPS
Sea Segment
VHF
Sensor
Networks
BEE
Legacy
MPLS
Data
Base
WiFi +
VHF
WiMax
DataBase
HiperLan
Strategic Operation Centre
Ground Segment
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.
30.09.2010
ACROSS
Page 72 of 127
Del.No.(D2.2)
Version: 1.0
Sensor
Temperature
Sensor
Pressure
Data
Writer
Application
Application
Subscriber
Publisher
<Temperature>
Confidentiality Level: PU
Subscriber
<Pressure>
<Pressure>
Data
Writer
Data
Reader
<Temperature>
<Temperature>
Data
Reader
Data
Reader
QoS Contract
Real Time Publish Subscribe
QoS
MANET
MPLS
QoS
TCP/IP
Satellite
VHF
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.
BEE™ Main Features
Predictable Data Distribution
30.09.2010
•
Multi-level Resource Management
•
Dynamic Network Resource Allocation
•
Data Classification and Shaping
•
Session Admission Control
•
Robustness to Intermittent Networks
ACROSS
Page 73 of 127
Del.No.(D2.2)
Version: 1.0
Resilient Data Distribution
Secure Data Distribution Services
Low Network Overhead
Confidentiality Level: PU
•
Ready for TACOMS standard for IP QoS (STANAG 4644)
•
No single point of failure (Serveless Architecture)
•
Embedded Reliable protocol (only Unicast)
•
Serverless Data Persistence
•
Serverless Data Source Hot Redundancy
•
Domain Access Control
•
Topic Access Control
•
Secure Discovery Protocol
•
Low Overhead Data Exchange Protocol
•
Offline Configuration for Static Network
•
Differentiated Physical Network Support for Management
and User Traffic
Model-Driven Architecture
11.6 Fault Assumptions and Behavior in Presence of Faults
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
DataReader
30.09.2010
Event name
Description
DataAvailable
A new data sample is available and
ready to be read.
ACROSS
Page 74 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
OfferedDeadlineMissed
A data sample has not been published
by the application within the deadline
timeout bound.
DataWriter
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
InconsistentTopic
A remote topic with the same name
but different data type has been
discovered.
SubscriptionMatched
A remote writer has been discovered.
Topic
DataReader
30.09.2010
ACROSS
Page 75 of 127
Del.No.(D2.2)
DataWriter
Version: 1.0
Confidentiality Level: PU
RequestedIncompatibleQo
s
A remote writer with incompatible
QoS has been discovered.
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
30.09.2010
Total cumulative count of samples rejected by
ACROSS
Page 76 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
RequestedDeadlineMissedStatus
totalCount
30.09.2010
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
ACROSS
Page 77 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
data was not received.
change The incremental number of deadlines
totalCount_
lastInstanceHandle
detected since the last time the listener was
called or the status was read.
Handle to the last instance in the DataReader
for which a deadline was detected.
RequestedIncompatibleQosStatus
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 78 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
totalCountChange
The change in totalCount since the last time the
listener was called or the status was read.
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.
totalCountChange
The change in totalCount since the last time the
listener was called or the status was read.
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 79 of 127
Del.No.(D2.2)
policies
Version: 1.0
Confidentiality Level: PU
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.
totalCountChange
The change in totalCount since the last time the
listener was called or the status was read.
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
30.09.2010
Total cumulative count the concerned
DataReader discovered a “match” with a
ACROSS
Page 80 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
DataWriter. That is, it found a DataWriter for
the same Topic with a requested QoS that is
compatible with that offered by the
DataReader.
totalCountChange
The change in totalCount since the last time the
listener was called or the status was read.
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 81 of 127
Del.No.(D2.2)
Event name
Version: 1.0
Confidentiality Level: PU
Status
Listeners
Method name
-
DataReaderListener,
SubscriberListener,
DomainParticipantListen
er
onDataAvailable
SampleLostStatus
DataReaderListener,
SubscriberListener,
DomainParticipantListen
er
onSampleLost
SampleRejectedStatus
DataReaderListener,
SubscriberListener,
DomainParticipantListen
er
onSampleRejected
OfferedDeadlineMissed
OfferedDeadlineMissedStatus
DataWriterListener,
PublisherListener,
DomainParticipantListen
er
onOfferedDeadlineMissedStatus
RequestedDeadlineMisse
d
RequestedDeadlineMissedStat
us
DataReaderListener,
SubscriberListener,
DomainParticipantListen
er
onRequestedDeadlineMissedSta
tus
PublicationMatched
SubscriptionMatchedStatus
DataReaderListener,
SubscriberListener,
DomainParticipantListen
er
onSubscriptionMatched
SubscriptionMatched
PublicationMatchedStatus
DataAvailable
SampleLost
SampleRejected
30.09.2010
DataWriterListener,
PublisherListener,
DomainParticipantListen
ACROSS
onPublicationMatched
Page 82 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
er
RequestedIncompatibleQosStat
us
DataReaderListener,
SubscriberListener,
DomainParticipantListen
er
onRequestedIncompatibleQos
OfferedIncompatibleQos
OfferedIncompatibleQosStatus
DataWriterListener,
PublisherListener,
DomainParticipantListen
er
onOfferedIncompatibleQos
InconsistentTopic
InconsistentTopicStatus
TopicListener,
DomainParticipantListen
er
onInconsistentTopic
RequestedIncompatibleQ
os
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.
11.7 Configuration interface (Interface to WP3)
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.sun.com/dtd/properties.dtd”.
30.09.2010
“java.util.Properties”
ACROSS
xml
file,
described
by:
Page 83 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 84 of 127
Del.No.(D2.2)
•
Version: 1.0
Confidentiality Level: PU
DiscoveryInitialAttempts (10)
Number of times that the participant discovery packet is sent with the 'DiscoveryInitialCycleDelay'
interval, then the interval will become 'DiscoveryCycleDelay'.
See the figure 2 below to see a graphical explanation.
•
DiscoveryCycleDelay (10000)
Time interval on which the participant discovery signal is sent after the initial phase.
See the figure 2 below to see a graphical explanation.
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 85 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 86 of 127
Del.No.(D2.2)
•
Version: 1.0
Confidentiality Level: PU
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 87 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
<networkConfiguration>
<!-- These are the default values for all the domains -->
<default networkInterface="" multicastDiscovery="229.0.0.1" defaultMulticastTopicData="229.0.0.2">
<discoveryAddress>255.255.255.255</discoveryAddress>
<discoveryAddress>localhost</discoveryAddress>
</default>
<!-- Just for example!! -->
<domain id="88888" networkInterface="10.180.2.0/24"
multicastDiscovery="229.0.0.3" defaultMulticastTopicData="229.0.0.4">
<discoveryAddress>10.180.2.6</discoveryAddress>
<discoveryAddress>10.180.2.4</discoveryAddress>
<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. 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.
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”.
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. If no one value is set, there are used the values: “localhost” and “255.255.255.255”.
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”.
30.09.2010
ACROSS
Page 88 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 89 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
12.1 Rationale and Covered Requirements
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 90 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 91 of 127
Del.No.(D2.2)
Version: 1.0
interface TraceControl {
ErrorCode addNetworkTrace(
out TraceID id,
in ComponentRange sender,
in ComponentRange receiver,
in PortRange port,
in long contentLength,
Confidentiality Level: PU
//
//
//
//
//
traceID associated with this trace
define range of traced senders
define range of traced receivers
define range of traced ports
define how many bytes to
trace from message content
// define offset into message content
in long contentOffset
);
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.
12.4 Dependency on Other Services
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 92 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
12.6 Fault Assumptions and Behavior in Presence of Faults
Not applicable. (The Real-Time Tracing Service is not part of the regular function of a system.)
12.7 Configuration interface (Interface to WP3)
To allow configuration of the Global Diagnostic Unit, information about all existing Components and
their component ID is needed.
30.09.2010
ACROSS
Page 93 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
13 OPT11: Debugging Service [LAUTERBACH]
13.1 Rationale and Covered Requirements
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 94 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 95 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
13.4 Dependency on Other Services
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.
13.6 Fault Assumptions and Behavior in Presence of Faults
Not applicable. (The Debug Service is not part of the regular operation of a system.)
13.7 Configuration interface (Interface to WP3)
To use the specified interfaces, an external tool needs information about the components contained in
the system.
30.09.2010
ACROSS
Page 96 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
14 OPT12: Health Monitoring Service (Local DU)
[LAUTERBACH]
14.1 Rationale and Covered Requirements
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 97 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 98 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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).
14.4 Dependency on Other Services
This service depends on the core communication services and the core clock synchronization services.
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.
14.6 Fault Assumptions and Behavior in Presence of Faults
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 99 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
14.7 Configuration interface (Interface to WP3)
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 100 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
15 OPT13 Health Monitoring Service (Global DU)
[LAUTERBACH]
15.1 Rationale and Covered Requirements
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 101 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 nonvolatile 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.
15.4 Dependency on Other Services
This service depends on the core communication services and the core clock synchronization services.
30.09.2010
ACROSS
Page 102 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
15.6 Fault Assumptions and Behavior in Presence of Faults
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).
15.7 Configuration interface (Interface to WP3)
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 103 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
16 OPT14: Virtual CAN service [TU Vienna]
16.1 Rationale and Covered Requirements
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 104 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
};
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.
16.4 Dependency on Other Services
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 105 of 127
Del.No.(D2.2)
•
•
Version: 1.0
Confidentiality Level: PU
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
TRM
App. Core
App. Core
CAN
Gateway
CAN
device
CAN
device
Off-Chip CAN Network
Time-Triggered Network-on-Chip
App. Core
App. Core
App. Core
CAN
device
I/O
component
CAN
device
Legend
TTNoC
Host
CAN Channel
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 eventsemantics, 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 106 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 severalreceive 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 107 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
No return value.
Return Value:
30.09.2010
ACROSS
Page 108 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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)
type (in)
id (in)
buf_hdl (in)
Return Value:
Handle of the CAN-link
“RECEIVE BUFFER” Buffer acts as a Receive Buffer
“REMOTE BUFFER” Buffer acts as a Remote Buffer
Message identifier
Buffer handle: Identifies uniquely the message buffer within a link
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)
que_hdl (in)
Return Value:
>0
=0
<0
Handle of the CAN-link
Queue-handle: Identifies uniquely the queue within a link
Number of messages in the queue
Queue Empty (CAN_RX_QUEUE_EMPTY)
CAN Return Codes
CAN_ReadQueueMsg
Description:
30.09.2010
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.)
ACROSS
Page 109 of 127
Del.No.(D2.2)
Version: 1.0
Parameter:
link (in)
que_hdl (in)
msg (out)
Return Value:
1
=0
<0
Confidentiality Level: PU
Handle of the CAN-link
Queue-handle: Identifies uniquely the queue within a link
Data structure to which the message is copied
A message was read (CAN_OK)
Queue Empty (CAN_RX_QUEUE_EMPTY)
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.
Parameter:
link (in)
buf_hdl (in)
Handle of the CAN-link
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.)
Parameter:
link (in)
buf_hdl (in)
data_p (out)
Len_p (out)
Return Value:
CAN Return Codes
Handle of the CAN-link
Buffer handle: Identifies uniquely the message buffer within a link
Data structure to which the data part of the message will be written
Data Length Code (i.e. number of bytes that should be interpreted in
data_p.)
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.
Parameter:
link (in)
buf_hdl (in)
data_p (in)
len (in)
Return Value:
CAN Return Codes
Handle of the CAN-link
Buffer handle: Identifies uniquely the message buffer within a link
Data field of the message
Data Length Code (i.e. number of bytes that should be interpreted in
data_p.)
CAN_TransmitMsg
Description:
30.09.2010
Writes a CAN message (Data Frame) to the Transmit Queue of a CAN link
ACROSS
Page 110 of 127
Del.No.(D2.2)
Version: 1.0
Parameter:
link (in)
msg (in)
Return Value:
CAN Return Codes
Confidentiality Level: PU
Handle of the CAN-link
CAN message
CAN_RequestMsg
Description:
Writes a Remote Frame to the Transmit Queue of a CAN link.
Parameter:
link (in)
id (in)
Return Value:
CAN Return Codes
Handle of the CAN-link
Identifier of the message that is requested by the Remote Frame
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
16.6 Fault Assumptions and Behavior in Presence of Faults
Event-triggered/Time-triggered Transfers
•
Queue overflows are detected by the service and forwarded to the diagnostic unit
16.7 Configuration interface (Interface to WP3)
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 111 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
16.7.2 Resource configuration
16.7.2.1 Trusted Resource Manager
•
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
16.7.2.2 Additional resources
•
Physical CAN Controllers interacting with the off-chip CAN network
•
If applicable, remote CAN nodes in external networks
30.09.2010
ACROSS
Page 112 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
17 OPT15: I/O Service [TTT]
17.1 Rationale and Covered Requirements
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 113 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
the design phase if not necessary.
17.3 Protocol
Constraints:
The user of IO_Service must call io_init ()before the first call to any other service call.
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.
17.4 Dependency on Other Services
Core services for sporadic and state message transport.
17.5 Description
TISS
driver
IO
Service
Application
Gateway
Service
IO Subsystem
I/O
Eth/TTE
Subsystem
TTEthernet
TTP Subsystem
TTP
TISS
driver
TNA
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 114 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 115 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 116 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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)
This status contains the following bits:
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.
Note: Multiple of these flags may be set together.
Other status bits will be defined in the implementation phase if necessary.
Data type: io_TTP_Command (32bit unsigned)
This status contains the following bits:
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 117 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
Other status bits will be defined in the implementation phase if necessary.
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)
This status contains the following bits:
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.
Note: Multiple of these flags may be set together.
Other status bits will be defined in the implementation phase if necessary.
Data type: io_TTE_Command (32bit unsigned)
This status contains the following bits:
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 118 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
off. It may take several time until the synchronization
between the networks is lost as they may drift slowly.
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.
Other status bits will be defined in the implementation phase if necessary.
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)
This status contains the following bits:
Status flag
Meaning
ETH_ERROR
Ethernet subsystem has detected an error.
t.b.d. in the design phase
Note: Multiple of these flags may be set together.
Other status bits will be defined in the implementation phase if necessary.
Data type: io_Eth_Command (32bit unsigned)
This status contains the following bits:
Command
Meaning
t.b.d. in the design phase
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.
Other status bits will be defined in the implementation phase if necessary.
Data type: io_Eth_Error (struct containing the error information).
API:
io_read_eth_status (io_Eth_Status *status);
30.09.2010
ACROSS
Page 119 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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.
17.6 Fault Assumptions and Behavior in Presence of Faults
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 Configuration interface (Interface to WP3)
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 120 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 121 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
18 OPT16: Mass Storage Service
18.1 Rationale and Covered Requirements
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 122 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
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 logevent must be captured by the service and saved into the log-file.
18.4 Dependency on Other Services
•
[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
18.6 Fault Assumptions and Behavior in Presence of Faults
•
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 123 of 127
Del.No.(D2.2)
o
o
o
o
Version: 1.0
Confidentiality Level: PU
Ignore, retry
In case of full memory: overwrite oldest value ( ring-buffer)
Stop logging from now on, throw exception
18.7 Configuration interface (Interface to WP3)
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)
18.7.2 Resource configuration
18.7.2.1 Trusted Resource Manager
• Ports and channels required to communicate with the storage component
18.7.2.2 Additional resources
30.09.2010
ACROSS
Page 124 of 127
Del.No.(D2.2)
Version: 1.0
Confidentiality Level: PU
19 Annex: Additional Requirements to D2.1
R 2.6.1 (S ta n d a rd Co m m u n ic a tio n P ro to c o ls )
The ACROSS platform shall support standard communication protocols for the Interconnection of
ACCROSS MPSoCs. Candidates are Ethernet or Time-Triggered Ethernet.
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
R 2.6.2 (Exe c u tio n o f P re c o m p ile d Co d e )
The execution of precompiled code should be supported by the operating system.
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
R 2.6.3 (Op tio n a l S e rvic e s S u p p o rt IP P ro te c tio n )
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).
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
R 2.6.4 (Do m a in In d e p e n d e n c e )
The optional services are domain-independent and support all targeted application domains.
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
R 2.6.5 (Fle xib ility o f th e s e t o f Op tio n a l S e rvic e s )
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.
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 125 of 127
Del.No.(D2.2)
Responsibility:
Requirement Status:
Requirement Source:
Version: 1.0
Confidentiality Level: PU
All WP2 partners
accepted
system-level requirement – R1.1.16, R1.2.11
R 2.6.6 (S ys te m He a lth Mo n ito rin g )
The optional services should provide health information with respect to their operational state (e.g., the
voting service should provide information about failed replicas).
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
R 2.6.7 (Le g a c y d e vic e d rive rs )
Device drivers for legacy networks (e.g., tcp/ip) have to be provided
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
R 2.6.8 (Bo u n d e d S ta rt-Up Tim e )
For a selected set of optional services (e.g., services for safety-critical hard real-time systems) the startup time has to be bounded.
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
R 2.6.9 (Co n fig u ra tio n Re p o rtin g )
The secure boot service (R2.2.3) should provide a unique identifier for each loaded application image.
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
R 2.6.10 (Ch e c ks u m s fo r Co m m u n ic a tio n )
The platform should provide a service for generating and checking checksums for the purpose of reliable
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 126 of 127
Del.No.(D2.2)
Responsibility:
Requirement Status:
Requirement Source:
30.09.2010
Version: 1.0
Confidentiality Level: PU
TU Vienna
accepted
system-level requirement – R1.9.10
ACROSS
Page 127 of 127