GENESYS - GENeric Embedded SYStem Platform::

Summary :: Objectives :: Progress :: Results ::Impact ::
Partners :: Environments :: Events :: Workshop ::
Documents ::Publications :: PR :: Links :: Contact ::

INTRANET
Contact
Impressum

Main results achieved

At month 9, the cross-domain architectureal style was defined.The GENESYS cross-domain architectural style encompasses fundamental architectural principles for robust embedded systems. Robustness concerns the handling of transient and permanent failures in the hardware, design faults in the software and intrusions. The cross-domain architectural style has been defined through a convergence of architecture views and concepts across the application domains. Each principle of the architectural style is an accepted statement about some fundamental insight in a domain of discourse. Principles form the basis for the formulation of operational rules. In GENESYS these principles are operationalized in the reference architecture template of the architectural service specification. The GENESYS architecture introduces three different integration levels: the chip-level, the device-level, and the system-level (see Figure 1). At the system level open and closed systems are distinguished. At each level, the architecture provides core services and optional services. The reason for the introduction of these integration levels is that the service characteristics of the three levels are substantially different, e.g., the bandwidth in a network-on-chip (NoC) is orders of magnitude cheaper than the bandwidth at the system level (e.g., WLAN). A major reason for distinguishing open and closed systems is that temporal guarantees can only be given in a closed system. At month 15, the industrial partners (from the automotive, avionic, industrial control, mobile and consumer electronics domains) have delivered reports on the assessment of the preliminary reference architecture template and the methodology framework. The assessment reports describe the degree to which the industrial requirements (e.g., composability) are fulfilled. In addition, the reports have produced recommendations of topics for future research projects and for improvements of the GENESYS architecture within the project by the technological work packages. For example, additional information addressing legacy reuse was requested. For this purpose, the establishment of the domain-specific architectures AUTOSAR, IMA, and NOTA on top of GENESYS has been outlined in the GENESYS book. In particular, it has been outlined how GENESYS maps to architectures using components at finer levels of granularity (e.g., software components and runnables in AUTOSAR).

At month 18, the reference architecture template was delivered. The reference architecture template is a template for building a concrete instantiation of the GENESYS architecture. The reference architecture template provides specifications for a comprehensive set of platform services. These platform services can be partitioned into the three service categories: core services, optional services and domain-specific services. The core services are mandatory and thus part of any instantiation of the GENESYS architecture. The core services are minimal in the sense that only those services that are absolutely indispensable to build higher-level services or to maintain the desired properties of the architecture are included in the set of core services. In GENESYS the core services must be amenable to certification. For this reason they must be deterministic and simple. The optional services build on these core services.

This is an open set of services that can be extended as needed. All or only a subset of these optional services can be selected for any particular instantiation of the architecture. Most of the optional services are implemented in self-contained system components that interact with the middleware of the application components by the exchange of messages. The domain-specific services are formed by a domain-specific subset of the optional services, augmented by special services that are characteristic for the domain under consideration. For example, in the automotive domain a CAN overlay network will be a domain-specific service, since most automotive applications use the CAN protocol.

In addition, the report on the final version of the methodology framework was delivered at month 18. This report describes a methodology framework for embedded systems engineering based on the GENEYS cross-domain architecture style and the reference architecture template. The report proposes methodology principles, such as a model-driven development with abstractions and transformations or model representation with support for different views, languages, and mappings. The methodology framework also introduces a process model for the application and platform development, which incorporates a platform module library as a repository with architectural services to be instantiated in specific systems. Furthermore, the report on the final version of the methodology framework contains an analysis of the suitability of UML MARTE for the methodology framework (e.g., for application architecture design).

Four prototype implementations of the GENESYS architecture comprise another main result that was delivered at month 18.

The first prototype focuses on composability, networking, and integrated resource management for industrial applications at the chip-level. This prototype interconnects IP cores through a predictable and deterministic time-triggered Network-on-a-Chip (NoC) with inherent fault isolation. It implements selected core and optional services of the reference architecture template, namely periodic messaging, sporadic messaging, streaming communication, clock synchronization, and voting.

The second prototype implements the GENESYS optional services for protected memory at the chip-level. It demonstrates the feasibility and the ability to instantiate the robustness services of the reference architecture template. The prototype provides results for both consumer and industrial domains. The memory protection services can be employed either to increase the production yield (e.g., in consumer applications) or to provide the appropriate trade-off between performance and protection levels (e.g. in industrial domains).
The third prototype builds upon the chip-level prototype and constructs a distributed system using Commercial-Off-The-Shelf (COTS) hardware. It demonstrates composability and the ability to meet hard real-time constraints at the chip and board level. In addition, this prototype evaluates fault containment properties required for the certification of avionic applications.
The fourth prototype demonstrates the management of the resources of a complex multi-processor SoC, which instantiates the GENESYS reference architecture template for consumer applications. A Global Resource Manager (GRM) is implemented, which supports a holistic view of resource usage and mediates resource reservation/allocation, as well as QoS negotiation.

Finally, a book has been a major result of the GENESYS project. The GENESYS book starts with a concise architecture overview presenting the cross-domain architectural style. Thereafter, the requirements from the industrial application domains and the consumer application domains are presented. Subsequently, the book describes the project results with respect to the development methodology and the tools. This part of the book focuses on the modelling framework for the development of applications based on the GENESYS architecture while incorporating quality properties. In addition, the book provides an overview of the reference architecture template with core services, optional services and domain-specific services at the different levels of integration. Finally, the relationship to existing domain-specific architecture is elaborated and a glossary defines key concepts used throughout the book.