R Obermaisser

H Kopetz

From ARTEMIS Requirements to a Cross-Domain Embedded System Architecture

Keywords: System Architecture, ARTEMIS, Composability, Robustness, Diagnosis, Cross-Domain Architecture

This paper gives an overview of the cross-domain component-based architecture GENESYS for embedded systems. The development of this architecture has been driven by key industrial challenges identified within the ARTEMIS Strategic Research Agenda (SRA) such as composability, robustness and integrated resource management. GENESYS is a platform architecture that provides a minimal set of core services and a plurality of optional services that are predominantly implemented as self-contained system components. Choosing a suitable set of these system components that implement optional services, augmented by application specific components, can generate domain-specific instantiations of the architecture (e.g., for automotive, avionic, industrial control, mobile, and consumer electronics applications). Such a cross-domain approach is needed to support the coming Internet of Things, to take full advantage of the economies of scale of the semiconductor industry and to improve productivity.

Introduction

Embedded systems enable the real-time computer control of physical devices and systems, ranging from mobile phones, to television sets, to automotive engines and to industrial robots (to take a few examples) in order to achieve an unprecedented level of performance and utility. In all of these domains the demands on the functional capabilities and the dependability of and consequently the opportunities for embedded systems grow rapidly as society moves further into the information age.

In this context, the ARTEMIS Joint Technology Initiative (JTI) was launched by the European Commission. Within ARTEMIS major European embedded system suppliers, OEMs and research organizations created a Strategic Research Agenda (SRA) with key challenges for more advanced embedded systems. Although the participants in ARTEMIS belonged to a broad range of application domains, many common challenges emerged. Composability and robustness are examples of cross-domain challenges that exist in embedded systems ranging from consumer electronic and mobile systems to safetycritical applications in the transportation sector.

Despite these cross-domain challenges, today's landscape of embedded system architectures is highly fragmented. Different system architectures have evolved in different application domains such as Integrated Modular Avionics (IMA) [START_REF] Arinc | ARINC Specification 651: Design Guide for Integrated Modular Avionics[END_REF] in the avionic domain, the AUTomotive Open System ARchitecture (AUTOSAR) [START_REF] Autosar | AUTOSAR -Technical Overview V2.0.1[END_REF] in the automotive domain or the Network on Terminal Architecture (NoTA) [START_REF] Kronlöf | A method for mobile terminal platform architecture development[END_REF] for consumer applications.

By advancing from the different domain-specific architectures towards a cross-domain embedded system architecture, this fragmentation can be avoided. Thereby, a significantly larger market for embedded system technologies (e.g., semiconductor devices, embedded components, software and tools) emerges. A large market and the resulting ability of exploiting the economies of scale is of particular importance for the semiconductor industry where the engineering costs associated with the design and tooling of chips grows rapidly. According to the International Technology Roadmap for Semiconductors (ITRS) the production of masks and exposure systems is becoming a bottleneck for the development of chips with finer geometries [START_REF]International Technology Roadmap for Semiconductors -2006 Update[END_REF]. For example, consider the design investments in the Cell Broadband Engine (CellBE) processor, which amount to 400 million USD [START_REF] Day | Hardware and Software Architectures for the CELL BROADBAND ENGINE processor[END_REF]. The cross-domain usability helps in amortizing such non-recurring costs.

In addition, a consolidation of embedded system architectures is needed to facilitate the interoperability of systems from different domains. Consider for example the electronic systems in a modern car, which encompass control subsystems, multimedia subsystems and gateways to mobile systems [START_REF] Albero | Automotive Forum. Electronics Technologies and Trends in Automotive Field[END_REF]. In particular, a consolidation is required to support the integration of systems into the Internet-of-Things.

Based on these insights, the European research project GENESYS (GENeric Embedded SYStem Platform) was launched, which took the ARTEMIS SRA challenges as a starting point and developed a candidate of a domain-independent reference architecture for embedded systems. By promoting a strict component-based design style and identifying services that can be deployed in different application domains, the design and production costs of new applications can be significantly reduced by reusing existing components and taking advantage of the enormous economies of scale of the semiconductor industry. GENESYS is a platform architecture that provides architectural services as a baseline for the development of applications. The architectural services consist of a minimal set of core services, which are domain-independent and deployed in every instantiation of the architecture. On top of the core services, optional services can be implemented as system components on top of the core services. These optional services, which can be domain-specific, are used to customize the GENESYS architecture for different applications. The remainder of the paper is structured as follows. Section 2 gives an overview of the ARTEMIS requirements. The GENESYS cross-domain architecture, which facilitates solutions to these challenges, is the focus of Section 3. Section 4 describes the core architectural services, which are mandatory in every instantiation of the GENESYS architecture. Examples of domain-independent optional services are discussed in Section 5. Section 6 provides examples of domain-specific optional services. The paper concludes with a discussion in Section 7.

ARTEMIS Requirements

The European Technology Platform on Embedded Systems, ARTEMIS, has proposed a Strategic Research Agenda (SRA) that outlines the most important areas requiring research in the context of embedded systems. Central to the ARTEMIS SRA is the concept of pan-application domain relevance of embedded systems research: the avoidance of further fragmentation in tools and techniques and multiple re-inventions of the wheel. One major axis of the SRA is "generic reference designs and architectures", i.e., reference architectures that can be used across multiple application domains. The following key challenges have been identified for such a reference architecture [START_REF]Strategic Research Agenda. Reference Designs and Architectures. Constraints and Requirements[END_REF]:

GENESYS Cross-Domain Architecture

This section gives an overview of the GENESYS cross-domain architecture. First the strict component-orientation of GENESYS is discussed. In addition, we provide information on the structuring of architectural services, which serve as a baseline for the development and integration of autonomous component services.

Component-Orientation

From the hardware and software points of view, the GENESYS architecture follows a strict component orientation. In GENESYS, a component is a self-contained hardware-software subsystem that is used as a building block in the design of a larger system. It encapsulates the implementation and hides the implementation details. The provided services are exposed via a set of message-based interfaces. Since a component hides the (complex) internal structure from its user, it offers an appropriate unit of abstraction for system design. Therefore, it helps to tackle the challenge of design complexity in large embedded systems.

The GENESYS architecture distinguishes between components in the logical view and the physical view. In the logical view a system consists of jobs that capture the behavior along with non functional properties while abstracting from the physical implementation platform (e.g., an FPGA, a general purpose CPU, the physical allocation). In the physical view of a system, three integration levels are distinguished: chip-level (level L1), device-level (level L2) and system-level (level L3). At the chip-level, the components of the physical view are IP cores. At the device level, the components are chips. The components at the system-level are devices.

Architectural Services

The capabilities of the platform are offered to the components, which realize the application services, by a set of architectural services. These architectural services are hierarchically structured as shown in Figure 1. At the bottom of this service hierarchy are the core services that define the platform. The core services must be present in every instantiation of the GENESYS architecture. Above these core services are the domain-independent optional services that provide enhanced capabilities to the users of the platform in order that functionalities that are needed in many, but not all application domains, are provided in a ready-to-use form. It is up to the user to decide, which one of these optional services are to be included in a concrete instantiation of the architecture. The implementation of these optional services uses the core services. At the next level of the hierarchy are the domain-specific services, which are highly specialized optional services of particular domains, followed by the application services, as shown in Figure 1.

The optional architectural services refine the core services for individual applications and application domains. Based on the core services, a broad range of higher-level optional services can be realized which are tailored to the requirements of specific application domains and refine or extend the core architectural services. The GENESYS architecture is intended to be used across multiple heterogeneous application domains with highly specific and potentially mutually contradicting requirements with respect to the architectural services. Examples of different requirements are the desired properties of communication protocols: Safety-critical applications (e.g., X-by-wire systems) have to deliver their application services in all specified load and fault scenarios. Therefore, safety-critical applications typically use communication services that are highly deterministic in the temporal domain (e.g., time-triggered protocols). In contrast, many non safety-critical systems have to be optimized for average load in order to reduce cost (e.g., in a multimedia system) and thus require flexible architectural services.

Additionally, optional architectural services have to be provided to support the reuse and the integration of legacy applications by emulating the corres-ponding legacy platforms. Examples are emulations of standard execution environments (e.g., a CAN [START_REF] Bosch | CAN Specification[END_REF] communication stack for automotive applications, a KHRONOS OpenMAX [START_REF]OpenMAX IL 1.1.2 Specification[END_REF] middleware for multimedia applications).

Consequently, the set of optional architectural services is extendable and configurable. Extendability is an important factor since it is not possible to anticipate how applications and their requirements will evolve in the future.

Configurability is required to facilitate the construction of resource-efficient systems. Therefore, the architecture is adaptable in such a way, that any particular instantiation contains only those services that are required in the actual system.

Core Services

The core services are mandatory in every instantiation of the architecture, since they form the foundation for all higher-level services. The core services can be grouped into four categories (cf. Figure 2): the basic time services, the basic communication services, the basic configuration services and the basic execution control services.

Basic Time Services

The basic time services establish a global time base, which allows the temporal coordination of distributed activities (e.g., synchronized messages), as well as to interrelate timestamps assigned at different components. The basic time services provide to each component a counter value that is globally synchronized within the given integration level. If the counter value is read by a component at a particular point in time, it is guaranteed that this value can only differ by one tick from the value that is read at any other correct component at the same point in time. This property is also known as the reasonableness of the global time [START_REF] Kopetz | Temporal firewalls in large distributed real-time systems[END_REF], which states that the precision of the local clocks at the components is lower than the granularity of the global time base. Optionally the global time base can also be synchronized with an external time source (e.g., GPS or the global time base of another integration level). In this case, the accuracy denotes the maximum deviation of any local clock of the integration level to the external reference time.

Basic Communication Services

The basic communication services enable the components to send unidirectional multicast messages on communication channels. The basic communication services support three communication modes: time-triggered, event-triggered and streaming communication. Time-triggered communication provides a predictable time-guaranteed messaging service, where the instants of message transmissions are specified by Finally, the primitive streaming communication enables the transmission and on-the-fly processing of a sequence of variable-size data elements (e.g., frames in a video stream) with corresponding temporal properties (e.g., average data rate with bursts). Similar to the sporadic message exchange service, this service uses also queues at the sender and receiver side. Queues compensate for irregular data rates that are typical for streaming applications (e.g., MPEG4). The primitive streaming service does not exercise any flow-control from the receiver to the sender.

Basic Configuration Services

The basic configuration services are needed to introduce the components to the platform and to connect the ports of the components for the establishment of the communication channels among the components.

The basic configuration services establish naming and connect/disconnect the ports and communication channels of the components according to a schedule that is provided to the basic configuration services by a scheduler. The basic configuration services determine the validity of the supplied schedule by checking whether collisions occur on the underlying communication medium (e.g., a networkon-a-chip at L1) and by evaluating a set of safety assertions. An example of a safety assertion would be a check whether the communication channels of the safety-related components are unmodified.

If the schedule is found to be valid, the basic configuration service sets the protected communication parameters of the involved components. These pro- In addition, the basic configuration service provides a unique identifier of the hardware under consideration (e.g., chip at L1, device at L2). This identification is tamper resistant as needed to inform the boot service about the type of available hardware and the attributes of the unit under consideration.

Basic Execution Control Services

The basic execution control services are used to control the execution of a component. Execution control is realized by sending an appropriate message to a local resource manager of the respective component. It is assumed that in every component there is such a local resource manager that accepts and executes the messages from the basic execution control service. The basic execution control consists of the following three commands:

(1) Execute Requests is a message requesting a component to start its execution at the next restart instant with the restart state that is contained in this message. In case this restart state is empty, the component will restart with the static restart data that are contained in its core image.

(2) Terminate Request is a message requesting a component to terminate its execution. The execution can be restarted with an Execute Request.

(3) Reset Request is a message that is interpreted directly by the component hardware without any control by the system or application software. It resets the component hardware and starts the execution until the point where an ExecuteRequest is awaited.

Domain-Independent Optional Services

These services build upon the core services and are generic in the sense that they can be used in multiple application domains. These services are optional in the sense that they are not required in every instantiation of the architecture. If needed, developers can pick them out of component libraries with existing, validated architectural services for the different levels of integration. The set of domainindependent optional services is open, i.e., new optional services can be added if the need arises. At present, the domain-independent optional services are grouped into the following categories (cf. Figure 2): diagnostic services, external memory management services, security services, resource management services, gateway services, mobility services, and generic middleware services.

In the following, the domain-independent services are exemplified using two of these categories, diagnosis and security, which represent two important cross-domain challenges.

Diagnostic Services

Many application domains -ranging from industrial systems to ambient intelligence applications -require the ability for monitoring the behavior of components in the value and time domains [START_REF]Strategic Research Agenda. Reference Designs and Architectures. Constraints and Requirements[END_REF]. The reliable identification of failed components can be used for the autonomous recovery of the system service in case of a transient failure, and provide guidance for the physical replacement of defective components in case the failure is permanent.

The GENESYS architecture provides a number of diagnostic services, which are implemented in a selfcontained diagnostic component. Based on the externalized information, a membership service provides a vector with a coherent global view of the operational status of the components [START_REF] Cristian | Reaching agreement on processor-group membership in synchronous distributed systems[END_REF]. The membership service simplifies the provision of many application algorithms, since distributed components can rely on the consistency of diagnostic information and react in a coordinated manner to detected failures. Another member of the diagnostic services is responsible for the analysis of diagnostic information.

The diagnostic analysis service checks the incoming ground state messages to find anomalies and records these anomalies in a local database. Additionally, error messages that are received from the components are examined. The application component implementations must ensure that all errors, even if they are masked by redundancy, are faithfully reported to the diagnostic component. An application specific diagnostic model analyzes all this data base information to assist the maintenance engineer in finding faulty components. Particular emphasis is placed to find out whether a transient, an intermittent or a permanent failure is present in a component, since the maintenance strategy is different for each one of these faults.

The component restart service resets and restarts a failed component with an internal state that is expected to be acceptable at the next future restart instant. The component restart service is also used to restart and perform state restoration in case of power gating.

Security Services

Security becomes a key issue when the connectivity of systems is increased beyond their traditional system boundaries (e.g., connecting parts of the invehicle electronic system of a car via gateways to the Internet in order to enable in-system updates). In addition, security becomes more and more important as consumer devices are used increasingly for identification, authorization, payment as well as for storage of sensitive personal information.

The GENESYS architecture provides by design mechanisms for the security related isolation of a job. The physical separation of the IP cores together with the one-to-one mapping between IP cores and jobs ensure data separation of different jobs. The restriction of the inter-component communication exclusively to message passing ensures by design that no hidden channels among components of different confidentiality can exist that bypass the passing mechanisms.

A basic identification service -the provision of a tamper-resistant unique identification of any GENESYS MPSoC is part of the core services. Using this core service, a dedicated optional security component can be provided that makes available enhanced security services, such as secure key management, encryption and decryption of all messages that leave or enter the MPSoC and a secure boot service. The objective of the secure key management is to establish a chain of trust. Keys are required for many cryptographic functions. In many cases the security of the system depends on the secrecy of the employed keys. Therefore, the keys should not be stored in plain text in the memory or on a disc, but have to be sealed in a cryptographic envelope. To operate on such an envelope a non-encrypted key is required, which is usually called the root key. The root key serves as the starting point for the chain of trust.

The secure key management service embeds the root key in a tamper resistant memory which guarantees that no other service or job can access it in plain text. Whenever a job or any optional service wants to access a key contained in an envelope (protected by the root key) it has to issue a decryption request to the secure key management services for that specific key. If the request is granted, the security key management service will decrypt the requested key in a protected region that can only be accessed by the security key management service itself. In the next step it delivers the decrypted key securely to the requester. The granting of decryption requests depends on the employed security policies (e.g., one possibility would be that only jobs authenticated by the secure boot service may have access).

The encryption and decryption service provides the basic algorithms for the encryption and decryption of messages given that the trusted keys are available.

The random number generation service generates true random numbers from a physical process as required in both symmetric and asymmetric cryptography for generating keys.

The secure boot service ensures that the binary image of the job itself that is downloaded from a trusted server has not been modified by an intruder.

It performs an authentication and integrity check on the job and it admits the job's execution only if the checks succeed.

The GENESYS architecture also provides application developers with basic mechanisms to access the services provided by the architecture as well as the application services built on top of the architectural services. Service authentication is performed when there is a request to register a service. Components that intend to use a registered service need to invoke an access control service in order to acquire the necessary access rights.

Domain-Specific Optional Services

The domain-specific optional services are services that are specialized for a considered application domain. The do-main-specific optional services build on the core services and a well-defined subset of the domain-independent optional services. In the following, two examples of do-main-specific optional services are explained.

CAN Communication and Gateway Service: A Domain-Specific Optional Service for Automotive Systems

The Controller Area Network (CAN) protocol [START_REF]ISO11898 -Road vehicles -Controller area network (CAN)[END_REF] is widely deployed in the automotive domain. For example, present day cars contain multiple CAN buses deployed in different subsystems such as comfort or powertrain [START_REF] Erjavec | Automotive Technology: A Systems Approach[END_REF][START_REF] Heppner | Assessment of whole vehicle behaviour by means of simulation[END_REF].

The CAN communication and gateway service is a domain-specific optional service for the automotive domain. This service enables components to interact using the CAN protocol. The mechanisms of the CAN protocol, such as message prioritization based on identifiers, acknowledgments, bidirectional request/reply patterns, are implemented on top of the communicated modes of the core architectural services. For this purpose, existing solutions for the establishment of CAN based on a time-triggered communication service [START_REF] Obermaisser | Reuse of CAN-based Legacy Applications in Time-Triggered Architectures[END_REF] can be exploited in the GENESYS architecture.

In addition, this domain-specific service supports the interconnection between a CAN bus and a communication network supporting the three communicated modes introduced in Section 3.2. For example, messages from a network-on-a-chip at L1 can be redirected to a CAN bus at L3. This gateway capability involves the provision of a physical interface (mechanical and electrical) that is compatible to CAN [START_REF]ISO11898 -Road vehicles -Controller area network (CAN)[END_REF], the address mapping from the internal addresses of the chip to the CAN identifiers and the protocol translation between the network-on-a-chip and the CAN bus.

Multimedia and Graphics Services: Domain-Specific Services for Consumer Applications

Multimedia and graphics is a mature domain, where solutions, standards and Application Programming Interfaces (APIs) exist that can be established in the GENESYS architecture. However, the core services of the GENESYS platform have to be available such that the domain-specific optional services for multimedia and graphics application services can be easily implemented.

Examples of domain-specific multimedia services supported in GENESYS are the services defined by the Khronos Group, and in particular the OpenMAX standards. The OpenMAX includes APIs at three abstraction levels (application, integration and development layers).

The application layer facilitates the capture and presentation of audio, video and images in multimedia applications on embedded and mobile devices. It includes the ability to create and control player and recorder objects and to connect them to configurable inputs and output objects including content readers/writers, audio inputs and outputs, display windows, cameras, analog radios, LEDs, and vibra devices. The integration layer defines a media component interface to enable developers and platform providers to integrate and communicate with multimedia codecs implemented in hardware or software.

The development layer contains a comprehensive set of audio, video and imaging functions that can be implemented and optimized on new CPUs, hardware engines, and DSPs and then used for a wide range of accelerated codec functionality such as MPEG-4, H.264, MP3, AAC and JPEG.

Discussion

Using the GENESYS architecture, significant improvements concerning time-to-market, cost, and robustness for a wide range of applications -from mobile phones to safety-critical computers in airplanes -are possible. Through its architectural principles (e.g., strict component orientation) and the generic architectural services, the GENESYS architecture contributes towards a cross-domain solution for the ARTEMIS challenges. In particular, GENESYS provides solutions to the following three challenges:

• Composability: GENESYS supports the straightforward composition of system out of independently developed components. System components can realize the generic optional services, while application components offer the application services. Thereby, the GENESYS architecture facilitates the establishment of a component-market for multiple domains. For example, a given security or networking component might be deployed in avionic as well as automotive and industrial control applications. Thereby, the transition from separate sectoral, vertically structured markets to a horizontally structured market is supported. The cross-domain GENESYS architecture results in a high volume market for generic components that can be reused in different application domains (i.e., automotive, avionics, industrial control, medical). Furthermore, the strict component orientation leads to systems that are decomposed into nearly autonomous parts with clearly defined interfaces. The GENESYS architecture reduces the complexity when integrating components by limiting the component interactions to occur exclusively via messages exchanged over the component interfaces (cf. basic communication services in Figure 2: periodic, sporadic and streaming communication). Also, the availability of a common notion of time as a core service enables the temporal specification of component interfaces in a way that the interactions of components in a distributed system can be temporally coordinated.

• Robustness: GENESYS supports the robustness of embedded systems by establishing a framework for fault containment and error containment, the selective restart of components that have failed after a transient fault, and the masking of transient and permanent errors by the replication of components. The waistline architecture encompasses optional services for voting (e.g., in a Triple Modular Redundancy (TMR) configuration), thereby performing active redundancy transparently to the applications. Furthermore, the global time, the clear notion of state, and the basic communication services support determinism as a basis for voting on a bitby-bit basis.

• Integrated Resource Management and Energy Efficiency: GENESYS provides for energy efficiency by an integrated resource management that makes it possible to individually reduce the power-requirements of components or to turn off components completely that are not needed during a particular interval (power gating). In addition to the basic configuration services, advanced dynamic resource management services can be provided by dedicated resource management components.

• Technology Obsolescence Management:

In a number of scenarios (e.g., aerospace industry, process control) the embedding system (the airplane or plant) has a significantly longer life-cycle than the embedded system. The component-based style of GENESYS makes it possible to modify the technology of a component implementation without a modification of the message-based component interfaces and the environment. In addition, the well-defined core services abstract from the implementation technology of the platform and permit changes of the platform without an impact on the application.

Figure 1 :

 1 Figure 1: Service Hierarchy in GENESYS

Figure 2 :

 2 Figure 2: Architectural Services

Acknowledgments

This work has been supported in part by the European research project GENESYS under project Number FP7/213322 and by the project INDEXYS under the Grant Agreement ARTEMIS-2008-1-100021.


D Verdier

Embedded system engineering as a solution to face future automotive industry challenges

Keywords: Automotive, system engineering, functional and physical architecture

Zero emission, zero accident, connected car, automotive industry is facing several challenges in which embedded electronic systems play a huge role. This paper describes the growing functional interdependencies and the related necessary rework of the functional architectures. The paper then analyses the feasibility of turning this functional architecture into a physical architecture, detailing the compromises an automotive architect has to find.

Introduction

Automotive world is today facing different, self opposing challenges. On one hand, society trends are driving the car to become a functional object in which embedded electronics systems play a huge role. But on the other hand, pressure for cost efficiency and quality tends to limit introduction of new components. The job of the architect is to identify the right compromise and match these two tendencies. Structured as a system engineering study, this paper will give keys in order to understand impact of society challenges on feature contents of the car, possible answers to these challenges at the functional level, and difficulties and trade-offs an automotive embedded system architect is facing when implementing in a real vehicle.

System Features: To face automotive industry challenges car has to become functional

Embedded electronics functions were limited twenty years ago to very few functions like ignition management. Today Society trends and pressure on car industry are turning car into a functional object in which electronic embedded systems are playing a major role. This reflects in the feature content of the car.

First objective is to increase road safety. This results not only in increased passive safety but also in increased active safety, with improved car stability trough coupling of systems acting on the different dynamic axis, creating new functional flows.

Another axis for road safety improvement is to increase driver perception with support of a set of environment sensors. Advanced driver assistance systems are emerging in the car, with a large spectrum of feature, from simple lane departure warning, though adaptive cruise control, to active collision avoidance. These assistance functions are creating new functional interdependencies. On one hand, the more active the assistance is, the stronger the link to chassis and drivetrain function will be. On the other hand driver workload needs to be carefully managed, in order to ensure efficiency of the assistance.

Figure 1 : Active and Passive Safety functions around crash

A second target of automotive industry is to fight emission of pollutant and greenhouse effect gas.

For more than 20 years, this fight has been residing in continuous improvement of internal combustion engines, with an intensive support of real time electronics. Functional granularity of control laws necessary to manage the complex phenomenon of combustion is increasing at each new pollution norm issue, introducing new sensors and actuators. This increased granularity is leading to resources problems when implementing. Consequently the internal combustion engine management could become more distributed than it was in the past.

But what is making torque production function even more distributed is introduction of electric drive, which introduces new functional challenges in the car.

Torque sources arbitration is needed in case of hybrid drives, in order to define the most energy efficient strategy for coupling electrical and thermal torque creation.

Regenerative braking is as well introducing functional impacts. For the first time, braking becomes a distributed function and mechanical link between pedal and caliper is broken. This feature will introduces a strong coupling between drive chain and braking function that wasn't required before. This coupling becomes even stronger when considering fully distributed torque production systems like wheel hub motors. Stability control, formerly in the sole perimeter of braking, is now distributed and partly realize by electric drives.

Electrical energy management is as well becoming critical in case of electric vehicle, with or without range extender, in order to ensure continuity of service of the vehicle and maximize the range. This energy management will require as well a new human machine interface, in order to inform driver about drive chain and battery status. For ten years, car industry has been struggling with providing access to services identical to the services provided by nomadic devices. As the consumer electronics world is evolving at a pace automotive can't industrially follow, solution seems reside in connectivity to these nomadic devices. That means making smart phones enabled services available in the car, audio streaming or internet for example, with the same man machine adaptation problem as for driver assistance function, in order to consider driving context. The car's being connected to outside world is as well bringing a huge opportunity of new car dedicated services. Not only from infrastructure to car downward information, like updated traffic information or fuel prices, but as well upward services or remote car control : Information once limited inside the car could be made accessible for outside usage. Preventive maintenance or fleet management are the first applications that one can think of when dealing with a connected car. But in context of electrical vehicle or car sharing, Phone activated thermal pre conditioning or access control could become mandatory. Main difficulty is that the functional architecture has to be flexible enough in order to adapt to services that may arise during ten years after it has been designed. But that spectacular explosion of new function should not lead us into forgetting that not all cars will be equipped with all options. Feature content definition is still today one differentiating aspect in car manufacturer's marketing policy.

Seeing the above depicted one can't deny that car manufacturers would require a single comprehensive functional architecture for their cars. Without it configuration management becomes difficult, and cross carline reuse policy becomes difficult. But a huge constraint is that this functional architecture needs to be modular enough in order to cover a very wide feature list spectrum, from affordable cars, with only basic functions like information display and engine management to high end cars containing the full spectrum of driver assistances. In parallel level of hybridizing propulsion, from basic stop and start to full electrical vehicle with wheel hub motors, is adding another layer of complexity on functional architecture. Functional architecture of the rest of the vehicle must not be impacted by a change in the management of the traction chain.

What could then be the main lines of such a functional architecture?

3. What functional architecture for the car in the future?

Today, car functional architecture of embedded electrical and electronic system is divided in clusters called domains. Number of domain may vary from one car manufacturer to the other, but a common acceptation can be found around 4 clusters: powertrain, chassis & safety, infotainment and comfort.

This split is mostly driven from history of automotive electronics.

Electronic ignition and later electronically controlled injection necessary to fulfill first pollution norms are the basis of the powertrain domain. Centered on the engine management electronic control unit, it now clusters all functions around positive torque management from thermal engine down to wheel, including transmission management.

Originated with first ABS systems, Chassis and safety domain is now containing much more than pure braking functions. It is now clustering all vehicle stability related function from basis Electronic stability control, to coupling between differential braking and steering actuation.

With their strong potential interaction with chassis actuator, ADAS like lane keeping are uselly associated to chassis and safety domain.

Passive safety, that is most of time considered to be as independent as possible, has functional interaction with ADAS and braking for pre crash management and therefore is considered as a sub domain of chassis and safety.

Infotainment was originally clustered around instrument cluster and radio. It deals with driver and passenger information and entertainment. Rather limited in entry vehicles, functional complexity of infotainment explodes with high end vehicles.

Infotainment will have to deal with management and broadcasting of numerous audio and video sources, while in parallel taking care of man machine interface not only for entertainment and comfort but as well for critical driving information and feedback. Historically embedded navigation is included as well in that domain. Problem is that this classical domain structuring, that is so well accepted that it reflects in the organization structures of the automotive companies, will have difficulties to deal with the functional interaction brought by evolutions of the feature content described in our first part.

Regenerative braking and distributed torque creation structure like in wheel electrical motors are creating a clear overlap between chassis and power train while ecological guidance is creating a clear relation between infotainment and powertrain.

Let's try to figure out what could our functional architecture look like when considering challenges described in part one, with the objective of minimizing the interactions between the obtained domains.

For complexity management reasons, hierarchical approach is mandatory to consider complete vehicle scope. Some rules can be defined for this analysis:

• All function in level N-1 contribute to realization of function N "Assist driver" can be divided in two : "assist driver in navigating" and "assist driver in driving".

Those two functions are relying on creating a model of the vehicle environment, analyze the vehicle behavior in such environment, identify driving situation and determine driver feedback strategy.

For "assist driver in navigating", infrastructure model is created, based on embedded map, but as well on telematics updated information, like maps, traffic, fuel price or availability of charge stations. Then an optimum route is computed based on criteria that could be context depending, for example on driver's chosen mode or batteries state of charge. Driver's feedback is most of time the sole output of this route analysis, but one can think also of a drive envelop limitation, for example when energy saving becomes critical in order to reach a given goal.

In order to establish eco guidance, "assist driver in navigating" requires a clear knowledge of energy storages management, required as well for driver information. To which domain does this new "manage energy storages" function belong ? let's finish our analysis before answering ! In case of "assist driver in driving", environment model is related to immediate vehicle surroundings, driving situation recognition relies on vehicle dynamics information generated in the execution/drive train domain, and actions can spread from driver feedback to generation of a new driving vector trough limitation of the "driving envelop". In order to avoid conflicts, the different assistances' output, feedback and driving vector for instance, need to be prioritized. As well in case of active assistance it is mandatory to consider arbitration function between driver requested driving vector and assistance proposed driving vector.

Figure 5: "Interface driver" function structure

What about scalability in such a functional architecture? Limit "acquire driver demand" to throttle pedal acquisition and interpreting in torque, limit assistance to torque regulation and limitation versus speed, embed the whole in engine management and you'll get a conventional car with cruise control. Now we will try to decompose "realize driver demand". Input would be a driving request vector. Realization strategy definition should be split from actuation level. Let's first speak about actuation function: "drive internal combustion engine", "drive transmission", "drive electrical drive(s)", "drive suspensions", "drive steering" and "drive braking". Paradoxically, though those functions are managing very complex system, they can be considered from the vehicle perspective as smart actuators: component designed in order to realize an applicative command, for example torque at crankshaft for thermal engine. These functions are as well responsible for the low level strategy in order to enssure efficiency and protect the actuator: Combustion management in thermal engine, power inverters control depending on electrical motor technology, and even ABS, that can be considered as a low level control loop of the braking system. This example of ABS gives us a good opportunity to discuss information management in such a functional architecture. ABS is the function that requires the wheel speed sensor information with the faster recurrence. Then it makes completely sense to acquire these sensors at the same level as the ABS function. As all other functions are using wheel speed info with a slower recurrence, only a downgraded is sent to the higher levels. Would another function require the same information with a quicker pace, this status would be reconsidered.

These "smart actuators" can't in all cases be controlled directly from the driving request vector. An arbitration and strategy definition level is required in order to determine the best actuation strategy. First example: Regenerative braking. Regenerative braking through the electro mechanical chain will depend on the maximum power the electrical storages can accept. For instance, this power will depend on the battery technology and state of charge. Based on the maximum recoverable defined by energy storages management, arbitration function will have to determine which amount of braking torque will be created using electrical motors in generator modes, and what is the necessary addition created from friction brakes. We see there that management of energy storages have as well interaction with execution/drivetrain domain.

On this example we can see as well that we only deal with actuation strategy, in a decoupled manner from chosen HMI. No matter whether regenerative braking is triggered by pressing a switch, releasing gas pedal or by pressing brake pedal, this strategy is clustered in the "interface driver" domain. In order to illustrate another aspect of the execution arbitration function, we will use the example of distributed torque production through wheel hub motors.

In such a structure, positive torque creation at each corner of the car can contribute to stability of the car, or impair it. This drives us into considering stability filtering as a control loop that should be added to the actuation arbitration function.

As for wheel speed information, Acquisition of vehicle dynamics information should be done in the same perimeter and sent to driver assistance function with a lower recurrence.

One must not forget that car should as well ensure access, comfort, entertainment and protection of passengers and payload. So an additional domain is required in our big picture: "welcome passengers", that would be composed of the functions mentioned above. Before giving hints on the content of each function, let's make a small precision: "passengers" here includes as well the driver, when not acting in his driving role. Passenger entertainment will principally deal with acquisition and broadcasting of entertainment sources. Connectivity to nomadic devices can be place in that function. It is to be noted that functionally, this connectivity is split from the one necessary for telematics.. "Protect passenger" will deal with conventional passive safety function. It requires a link to driver interfacing, for pre-crash and emergency braking situations identification. "Ensure passengers access" clusters all access control and accessibility functions. It may be impacted by car sharing in the future. As well, "Ensure passenger Comfort" will be impacted. It will have to adapt to specificities of electrical vehicle. Basically this domain deals with thermal and acoustic management of passenger compartment. In electrical vehicles, a thermal comfort vs range tradeoff establishes. Thus thermal management will have to be context dependent. It will have to adapt to number of passenger, to level of energy in the storages. Once more a link to energy storage management! Staring at the picture described above, we can now figure that a specific domain for energy storage management may be required. Formerly hidden in the comfort domain in conventional car, it takes clear importance when considering electrical and hybrid vehicle management. As already mentioned information about battery state of charge or acceptable power is becoming a central information used for function spreading from thermal comfort management to arbitration of driving strategies. What about range extender in such a frame? Functionally, control of this internal combustion engine driven generator is integrally part of the power management domain. Internal combustion engine in range extended electrical vehicle is not taking part in the driver demand realization; crankshaft torque is not transferred to wheels. So in that case Internal Combustion engine management is functionally transferred from execution/drive train domain to energy storage management. Anyhow content of the engine management will differ and may be simplified due to the operation of engine in nearly steady states.

As a conclusion to this part, we can see that through hierarchical functional analysis, starting from vehicle level, we could come to restructuring the car functional architecture into four domains: "interface driver", "realize driver demand", "welcome passengers" and "manage energy storages" With this approach, a satisfying level of genericity and scalability can be obtained. Let's now have a look at the constraints when implementing it into a physical architecture.

Getting physical: difficulties of implementing a functional architecture into a real car

Electronic embedded system architect have to define physical architecture according to two axis : electronic architecture and electrical architecture.

For electronic architecture definition, meaning mapping of software functions on electronic control units (ECUs) and definition of communication channels between these ECUs, Autosar based methodology and tool chain represents a real support for system architect. Indeed, virtual functional bus based integration phase will be a real support to migrate from the functional architecture to the software architecture, But things become difficult when considering the electrical architecture definition. There need to be defined: Wiring harness routing and physical split, Electronic Control Units (ECU) pining and packaging, servitudes management, for instance multiplexed life phases and terminal management, and related power distribution.

Major difficulty with passenger car is that it represents a very constrained physical target; Packaging spaces for control units are limited and have shapes that are deformed by structural design or by styling constraints.

Car has also to be produced in very large series, with production of several hundreds of thousand units per year, sometimes up to one million on one platform.

As a consequence quite commonly known, cost hunting is the priority of the architect, as a few euro savings on a car turn into millions at the end of the year. One must not forget than costs are hiding not only in material price but also in the complete design, logistics and assembly process.

Number of part and number of reference for each of these parts must be limited, therefore complexity management is critical and it is directly impacted by electrical architecture. Complexity is measured through the number of reference of each product necessary in order to realize the complete marketing definition of the car, when taking into consideration take rates. This criterion is particularly important for wiring harness. Indeed complexity management represents a non negligible fraction of the wiring harness cost. Architecture can contribute to reduction of this wiring harness complexity and sometimes to its increase. In multiple piece harness it is important to decouple the complexity of each harness.

For example connector of an high-speed CAN node connector can't be left in the car when the car is not equipped with the related ECU. So there are reference with or without this connector, it creates a combinatory in the references calculation for the wiring harness. Let's assume this node is connected to roof harness. If this sensor is supplied with power from a fuse attached to a body harness and passing through an inline connector, combinatory will impact both harnesses. If it is powered from a fuse directly connected to the roof harness, complexity will only impact roof harness. Sometimes a change in the marketing definition of the car, for example options grouping, is necessary in order to ensure industrial feasibility of wiring harness. Possibility to assemble parts of the architecture in the car in an efficient manner is essential and must be kept in mind all along the architecture definition process.

Let's take an example, to illustrate danger of not considering those aspects. Imagine an architecture aiming at simplifying the body controller, with a single board concept where two boards were necessary before. Complete design is done, architecture is functionally viable. But, in the body controller, single board constraint led electronics designer into pushing one of the connectors closer to side of the product. This slight change in the connector position was making access very difficult to that connector when dashboard was mounted, connecting the related wiring harness being then very difficult for the operator on the assembly line.

As no economically viable solution was found to contain that technical risk, the complete electrical architecture scenario was abandoned.

In addition, as investment are very high, any technical choices in electrical architecture definition that leads to a change of the assembly line needs to prove high economical efficiency, with the danger of being rejected otherwise. This slows also the pace of technical changes in architecture.

These constraints represent some primary architecture selection and comparison criteria. Let's study some other criteria and how they impact functional architecture implementation.

Performances as response time, multiplexed network load, but as well capacity to withstand electrical demand need to be verified. Part of it can be checked trough simulation versus requirement defined in the functional architecture. We reach there another trade off for the architect : for cost reasons some functions that are independent in the functional architecture will have to share common resources, like processors, network, or even antennas or displays. When proposing such integration, architect should ensure that resources can support the need of the integrated functions in order to avoid costly material upgrades. This applies not only to concerns like processing power, but as well to a lot of other limitation like for example limits in the pining of the ECU for connector packaging reasons.

Reliability, Availability, Maintainability and Safety (RAMS) criteria are also to be considered when designing the architecture. Safety concepts of safety critical function is primarily defined at the architecture level and choices in that domain can drive over costs quite rapidly. Lets take the example of electrical steering column lock management. Used in keyless start this device brings the risk of locking while the vehicle is rolling. Some architects are pushing the strategy to distribute the safety concept over several already existing ECUs, while other prefer to have it centralized. The second solution results in a huge over cost in the ECU design, while cost impact of first solution is only limited to the lock itself.

Safety concerns represent also a difficulty in heterogeneous function integration. For example should display of MP3 ID3 tag in instrument cluster endanger display of vehicle speed? Defining such architecture requires good understanding of available technologies and their cost impact. Very difficult to evaluate during architecture design phase, quality and reliability of the overall system must nevertheless be considered due to impact on the brands image. Return on experience from the field must be considered in the design of the architecture.

We will finish this list with two criteria of quite an high importance: downward compatibility and scalability.

Downward compatibility constraint is highly impacting implementation of the functional architecture. For investment reasons most of component that are used across several carlines are not redesigned. This has impacts on the complete architecture: impacts on electrical architecture, impacts on electronic architecture, even our functional architecture may be impacted. Electrically, compatibility of connectors, power supply and terminal management for these loads must be ensured. Electronically, multiplexing compatibility must be ensured, limiting evolutions and optimizations that can be made on message matrix. Functionally, as the functional content of such component is frozen, it may not be consistent with a reworked functional architecture; it limits then the implementation of innovative functional architecture. In the future, this last problem should be partly solved by the flexibility brought by Autosar once it will be more widely implemented.

Last but not least, Scalability. Scalability represents the ability of the architecture to realize content of each equipment level at an optimized cost. It represents a real challenge for generalist OEM, the marketing definition of car spreading from very low end with almost no features, to high end with full features, with several levels of equipment and their options combinatory. In particular, scalability concerns are driving decision on the functional integration we can do in the several electronic control units of the architecture.

Then what integration scenario should we promote for our functional integration? One function-one box isn't acceptable. Considering electrical architecture it is a nightmare: number of ECUs to package and mount in the car would be definitely too high, number of fuses required for power distribution would be huge. In terms of flexibility, it could seems perfect, only what is needed is mounted in the car, but when having a closer look we come to realize that it is not optimized for any of the equipment levels.

In parallel, with processing power increase, one could think of one functional domain, one ECU. This is quite unlikely as well. Sensors and actuators related wiring harnesses and connectors will make this ECU difficult to assemble in the car. One could think of smart sensors and actuators to solve this issue, but this would be pushing the cost issue to these components. Safety concepts in such architecture would be difficult to analyze, with costly functional independence management structures to be implemented in the hardware and software design. As scalability is concerned, this solution is quite cost optimized for high end, but it will represent by far a too high infrastructure cost for the low end to bear.

So integration solution stands somewhere in the middle, depending on the marketing mix of the vehicle. Integration should be favored for function with significant take rate, and located in the same area of the marketing mix. This theory is of course once more limited by the physical and safety feasibility of the integration concepts. As a conclusion we can see that the physical implementation of a functional architecture is subject to so much car and OEM dependant constraints that no genericity can be found at the complete vehicle level. Architecture design remains a matter of compromise finding, in which the architect is playing a huge arbitration role. Functional architecture studies have nevertheless an impact on the physical level. They help a lot in structuring the bricks of an electronic design platform, bricks that could be made generic even if the assembly in a complete ECU is application dependant.

Conclusion

Next ten years' automotive challenges are bringing so much the functional impacts in the standard car feature, that a complete rework of the car functional architecture may be necessary. Domain oriented, this architecture could be subject to a certain level of standardization.

But in parallel, mass-production, styling, reuse and marketing constraints prevent us from finding a generic answer at the physical level. The reworked functional architecture can then be seen as an asymptote, migration pace to new functional architectures will be highly depending on the car manufacturer strategies.

Figure 2 :Figure 3 :

 23 Figure 2: Drivetrain architecture functional drivers Driver education and assistance with the objective to reach a more ecologically friendly driving style is as well foreseen as one way to reduce energy consumption in car usage. Ecological guidance becomes even mandatory in usage of electrical vehicle, which range is limited. One application could be to define the most energy efficient way considering an updated context, for example traffic conditions or charge station availability. It introduces a close link between energy management, drive train, navigation and telematics functions. Once more, introduction of new functional dependencies in the car ! Consumer Electronics pressure Services Passenger Friendliness New Driving HMI Body and Passenger management Driving management and support

  Figure 4: Connected car

Figure

  Figure 6: "Realise driver demand" function structure

Figure 7 :

 7 Figure 7: Overview of the functional architecture

  Figure 8: Typical electronic architetcure

Figure 9 :

 9 Figure 9: Example of multipiece loom harness

  Figure 10: illustration of a possible integration strategy

  Finally comfort domain is gathering passenger comfort related function. From single zone to multiple zone Climate system, from simple electrical windows to global closing, from central door locking to keyless access and start, functional complexity is quite high in comfort domain. Comfort domain includes as well all servitude function like electrical board net state management and multiplexing network management. Indeed, comfort domain is originally clustered around body controller control unit, kernel of the electrical and multiplexing networks. Despite its name comfort domain is critical for the car to operate properly.


Ph.D A Corsaro
email: angelo.corsaro@prismtech.com

Addressing the Data Distribution Challenge in SCADA and Utilities Systems

Keywords: Real-Time Data Distribution, OMG DDS, SCADA, Utilities, Middleware

SCADA and Utilities Automation systems, such as power grid control, industrial automation, and high throughput telemetry systems, must increasingly meet the need to (1) deal with more data in a timely and predictable manner, often over a widening geographical scale, (2) provide secure communication, (3) provide filtering capabilities that help optimise data distribution and sense-making, and (4) reduce time-to-market. Conventional infrastructure software technologies fall short in addressing most, if not all, of these requirements due to their lack of flexibility and configurability, limited support for dealing with large volumes of data, lack of security, data filtering, and limited expressiveness and productivity. This paper introduces the OMG Data Distribution Service for Real-Time Systems and highlights how its features ideally address the key requirements of existing and next generation SCADA and Utilities Applications.

Introduction

SCADA and Utilities Automation systems, such as power grid control, water and wastewater management, industrial automation, railway control systems, and high throughput telemetry systems, must increasingly meet the need to (1) deal with more data in a timely and predictable manner, often over a widening geographical scale, (2) provide secure communication, (3) provide filtering capabilities that help optimise data distribution and sense-making, and (4) reduce time-to-market. Conventional infrastructure software technologies fall short in addressing most, if not all, of these requirements due to their lack of flexibility and configurability, limited support for dealing with large volumes of data, lack of security, data filtering, and limited expressiveness and productivity.

The steadily growth in adoption of mainstream COTS (Consumer-Off-The-Shelf) technologies for the communication layer, such as, Ethernet, and Industrial Ethernet, along with the established trend toward processor architectures such as PPC-or x86-microprocessors, is enabling the use of software technologies that provide extended functionalities along with improved productivity, thus opening a new set of possibilities for architecting and implementing distributed real-time sensing/monitoring and control systems such as those found in SCADA and Utilities.

The Data Distribution Service (DDS) for Real-Time Systems [1,2,3], a standard-based publish/subscribe middleware defined by the OMG, is a COTS technology that is experiencing a constantly growing adoption in SCADA and Utility applications. This success is mainly due to its ability to address the challenges outlined above by providing (1) a very powerful data distribution and event processing model, (2) extremely high performance, (3) hardreal-time determinism, and (4) a rich set of nonfunctional properties fully configurable by means of Quality of Service (QoS) policies, used to control properties, such as, deadline, data prioritisation, data availability, as well as resource (network, CPU, and memory) usage and reservation. In addition, leading implementations of this standard [4] also provide information assurance thus securing data communication, enforcing access control, and information flows.

OMG DDS: The Data Distribution Service for

Real-Time Systems

Overview

The Data Distribution Service for Real-Time Systems (DDS) is an Object Management Group (OMG) standard for Publish/Subscribe (Pub/Sub) that addresses the needs of mission-and business critical applications, such as, financial trading, air traffic control and management, and complex supervisory and telemetry systems. That key challenges addressed by DDS are to provide a Pub/ Sub technology in which data exchange between producers and consumers are:

• Real-time, meaning that the right information is delivered at the right place at the right time--all the time. Failing to deliver key information within the required deadlines can lead to life-, missionor business-threatening situations. For instance in a financial trading 1ms could make the difference between loosing or gaining $1M. Likewise, in a supervisory applications for power-grids failing to meet deadlines under an overload situation could lead to severe blackout such as the one experienced by the northeastern US and Canada in 2003 [1].

• Dependable, thus ensuring availability, reliability, safety and integrity in spite of hardware and software failures. For instance, from the reliable functioning of an Air Traffic Control and Management System depends the life of thousands of people flying over the area it is managing. Thus these systems have to ensure 99.999% of availability and guarantee that regardless of experienced failures critical data is reliably delivered.

• High-Performance, hence able to distribute very high volumes of data with very low latencies. As an example, financial auto-trading applications have to deal with millions of messages per second each of which has to be delivered with minimal latency, in the order of tens of microseconds.

The OMG DDS standards family is today composed, as shown in Figure 1, by the DDS v1. In essence, the presence of a GDS equipped with dynamic discovery means that a deployment time, no configuration is required for the system.

Everything will be automatically discovered and data will begin to flow. Moreover, since the GDS is fully distributed, nobody has to fear the crash of some server inducing unknown consequences on the system availability --in DDS there is no single point of failure, although applications can crash and restart, or connect/disconnect, the system as a whole continues to run.

When compared with other publish/subscribe technologies, DDS crisply stands out because of (1) its powerful support for data modelling, event filtering and processing, and (2) its support for a very rich set of QoS which allow to configure the most important properties of data distribution, such as its temporal properties, its priority, its availability, and its presentation.

2.2 Data Modelling DDS perfectly blends and extends the most useful features found in real-time messaging middleware and relational databases. From real-time messaging middleware, DDS draws the efficiency in distributing data, the low-latency, the real-time determinism, and the throughput. From relational databases, it draws the ability to define relational data models and operate on them via SQL92 expressions to specify content-based subscriptions, join, projection, filters, and queries (see Figure 3). DDS allows the application programmer to create object views from a relational information model. This ensures that the applications logic can completely focus on the business problem, while delegating to the middleware the mechanics of data distribution.

Another typical use of the object-oriented view is to reconstruct and manage relationships out of the messaging data, perform complex filtering, and correlation. As shown in Figure 3, DDS can perform data filtering and correlation by relying on either SQL92 expressions, or on user provided filterobjects.

All these capabilities are provided via a fully distributed architecture that ensures performance, predictability, availability, and scalability, and are controlled and finely-tuneable by a rich set of QoS policies that allow traffic prioritisation, traffic shaping, hardware and software filtering, and persistence.

The native support for relational information modelling makes it very efficient to seamlessly integrate DDS implementations with databases.

Moreover, the combination of data filtering-by means of content-based subscriptions-and event processing-by means of filter-objects-allows the execution of arbitrary complex event filtering and correlation in the middleware, thus providing the application with only the events it is really interested in.

Figure 3: DDS Relational and Object-Oriented Data Modelling

The DDS Data Modelling features enable scalable modular application designs that effectively separate the data acquisition processing and communication modelling from the business or engineering processing that transforms acquired data into strategic control information. For example, largescale SCADA systems are often combined with Energy Management Systems (EMS) that transform sensor data into control strategies for efficient and safe control of generation and transmission resources.

Separation of data acquisition and t r a n s p o r t c o n c e r n s f r o m c o m p l e x d a t a transformations are combined with the powerful relational information modelling capability of DDS to enable highly advanced application frameworks for evolving SCADA/EMS applications.

Quality of Service

Application domains like SCADA/EMS can rely upon DDS as a sure foundation for robust and reliable data acquisition and transport functions. DDS provides a rich set of QoS policies for finely tuning and controlling the data temporal properties, e.g., deadline, latency budget, etc., its priority, reliability, persistence, and resource usage. This set of QoS policies provide the control knobs that allow an architect to specify how the system should behave, thus making it possible to easily express the constraints derived from schedulability analysis and alike.

Two key sets of DDS QoS policies relevant to SCADA and Utilities applications are those controlling data timeliness and data availability. DDS provides a rich set of QoS policies that control the timeliness properties of distributed data, the trade-off between latency and throughput, and the data prioritisation:

• The LATENCY_BUDGET QoS policy provides a means for applications to inform DDS of the urgency associated with transmitted data. The latency budget specifies the time period within which DDS must distribute the information. This time period starts from the moment the data is written by a publisher until it is available in the subscriber's data-cache ready for use by reader.

• The TRANSPORT_PRIORITY QoS policy allows applications to control the importance associated with a topic or with a topic instance, thus allowing a DDS implementation to prioritise more important data relative to less important data.

• The DEADLINE QoS policy allows applications to define the maximum inter-arrival time for data. DDS can be configured to automatically notify applications when deadlines are missed.

These QoS policies make it possible to ensure that (1) the system is tuned to operate in the right latency/throughput trade-off point, and (2) that important data is always able to preempt less important data, thus ensuring that even in overload condition the temporal properties of critical data are preserved. As an example, the combination of the

L A T E N C Y _ B U D G E T , D E A D L I N E a n d
TRANPORT_PRIORITY can be used to set the properties needed to enforce the schedulability of data traffic as derived from a Rate Monotonic Analysis (RMA).

DDS provides the following QoS policies that control the availability of data to subscribers:

• The DURABILITY QoS policy controls the lifetime of the data written to the global data space. Supported durability levels include (1) volatile, which specifies that once data is published it is not maintained by DDS for delivery to late joining applications, (2) transient local, which specifies that publishers store data locally so that late joining subscribers get the last published item if a publisher is still alive, (3) transient, which ensures that the global data space maintains the information outside the local scope of any publishers for use by late joining subscribers, and (4) persistent, which ensures that the global data space stores the information persistently so it is available to late joiners even after the shutdown and restart of the system.

• The LIFESPAN QoS policy controls the interval of time during which a data sample is valid. The default value is infinite, with alternative values being the time-span for which the data can be considered valid.

• The HISTORY QoS policy controls the number of data samples (i.e., subsequent writes of the same topic) that must be stored for readers or writers. Possible values are the last sample, the last n samples, or all samples.

These QoS policies control the degree of time decoupling between publishing and subscribing applications, as well as the historical data that the middleware should keep on behalf of the application. Several other QoS policies exist that control (1) the replication of publishers, greatly simplifying the implementation of Hot-Swap and Hot-Hot replication styles, and (2) the use of computational resources, such as main memory, buffer sizes.

These DDS QoS policies allow highly decoupled and focused data transformation applications to be designed and deployed in a truly distributed architecture that leverages available computing and communication hardware technology with data transport agnosticism. An example of this is the SCADA/EMS application domain where it is essential that intensive compute and data hungry optimisation algorithms or electrical system contingency analysis solutions be decoupled architecturally from relatively simple but time critical resource allocation control operations.

Traffic Engineering

In addition to the DDS QoS policies that control the temporal properties of data, it is worth investigating how these QoS are leveraged by some of the most advanced DDS implementations [4] to enforce specific network traffic properties. • Latency/Throughput Tradeoff. Advanced DDS i m p l e m e n t a t i o n s , r e l y o n t h e LATENCY_BUDGET QoS to bundle data across topics and applications to ensure optimal throughput and reduce CPU utilisation.

• D a t a

P r i o r i t i s a t i o n .

T h e TRANSPORT_PRIORITY QoS is used in combination with network channels to enforce messages priority even on non-prioritypreserving transports, such as the TCP/IP or UDP/IP.

• Traffic Shaping. For every channel it is possible to define the traffic profile to ensure that the network utilisation never exceeds a userspecified value.

• Traffic Partitioning. DDS partitions are mapped to IP multicast addresses to segregate different traffic flows and rely on hardware filtering capabilities provided by modern routers, switches and network cards.

The combination of these architectural features and QoS ensure that DDS applications have full control over the characteristics of generated traffic. As a result, the system can be properly tuned and configured to operate at the right performance point, while retaining stability and determinism during overload conditions. way that ensures transparency to the applications, thus supporting full portability. This solution provides QoS-enabled IA offering end-to-end security between all applications (distributed or co-located), including mandatory access control for all data flowing between applications and detailed security audit of application interactions.

The security solution extend the real-time communication with configurable cryptographic protection implementing the following security properties:

• Information exchanged over unsecured networks cannot be eavesdropped or modified without detection while in transit (data integrity & confidentiality).

• Complete, reliable, and readily evaluable separation between the area in which the information is processed in unencrypted form (RED, on the node) and the area to which critical (classified) information is not permitted to flow in unencrypted form (BLACK, network). \

Concluding Remarks

The Data Distribution Service (DDS) for Real-Time Systems is a standard data-centric, topic-based publish/subscribe middleware that has been designed for addressing the data distribution challenges of real-time distributed systems. Due to its high performance, powerful support for data modelling, event filtering and processing, and its finely tuneable control over key properties of data distribution, such as deadline, priority, latency, availability, and security, DDS is the perfect technology for addressing the data distribution needs of the most challenging SCADA and Utility applications. Companies that should seriously consider deploying DDS are (1) companies developing utility automation such as power-grid control, looking for more scalable and high performance data distribution middleware, (2) companies struggling with keeping up with high volume telemetry systems, who are looking for a standard-based solution that can cope with massive volumes of data in real-time to either replace homegrown solutions, or under-performing proprietary solutions, (3) Industrial control companies that want to fully leverage their move to Ethernet or Industrial Ethernet, and are looking for more productive data distribution middleware that can be easily integrated with enterprise systems. OpenSplice DDS, www.prismtech.com/openplicedds.

Glossary

COTS: Components Off The Shelf DDS: Data Distribution Service for Real-Time Systems EMS:

Electronics manufacturing service GDS:

Global Data Space Pub/Sub: Publish/Subscribe OMG:

Object Management Group QoS:

Quality of Service SCADA: Supervisory Control and Data Acquisition

  2 API [2] and the DDS Interoperability Wire Protocol (DDSI v2.1) [3]. The DDS API standard guarantees source code portability across different vendor implementations, while the DDSI Standard ensures on the wire interoperability across DDS implementations from different vendors. The DDS API standard defines several different profiles (see Figure 1) that enhance real-time pub/sub with content filtering, persistence, automatic fail-over, and transparent integration into object oriented languages.

Figure 1 :

 1 Figure 1: The DDS Standard

Figure 2 :

 2 Figure 2: The Data Distribution Service Conceptual Model

Figure 4 :

 4 Figure 4: DDS Networking Technology and Traffic Engineering

2. 5

 5 Information Assurance Leading DDS implementations [4] provide security solution ensuring Information Assurance (IA) for all DDS-based cooperation and information exchange b e t w e e n t h e D D S n o d e s o v e r u n t r u s t e d communication infrastructures. The security solution allows the reliable separation of applications with different clearances deployed on different nodes in a