Support for Hardware Devices in Component Models for Embedded Systems

Transcription

1 Support for Hardware Devices in Component Models for Embedded Systems Luka Lednicki School of Innovation, Design and Engineering Mälerdalen University October, 2009

2 Contents 1.Research topic Research methodology Central literature Related work Component models Hardware description languages and middleware technologies Key conferences References...7

3 1.Research topic As modern embedded systems grow in complexity Component-Based Development (CBD) is an increasingly attractive approach utilized to make the development of such systems simpler and less error prone. Component-based approach can introduce many benefits to system development, such as reuse of software components, easier system composition, analyzability of systems composed of components, etc. However, in the embedded system domain these benefits are still seldom used in practice, and mostly explored in component models used only in research context. One of the main characteristics of embedded systems is that they interact with their environment. This interaction can be as simple as writing value to a hardware pin or port of the device that the system is deployed on, or as complex as invocation of a service on a remote device. In all cases, this interaction with the environment implies dependencies of software components on the hardware or middleware used to communicate with the environment. Same environment, and combination of hardware and middleware also affect the behavior of an embedded system. As reusability and analyzability of software components and component based systems highly rely on such dependencies and effects on behavior, failure to adequately express them can hinder the use of component-based approach in the embedded system domain. Current component models for embedded systems used in research most often focus on providing support for handling only software components and rarely try to provide comprehensive approach for dealing with components dependent on external devices. The research goal is to investigate the possibility of efficiently building component-based systems, in a combination of software and hardware components, in modeling of their behavior (execution) and some of extra-functional properties. Dependencies on external devices affect component models on many different levels. From the architectural point of view, such dependencies have to be clearly stated and presented for developers to be able to see and manage them. In the deployment phase, software components and subsystems are allocated to the underlying hardware that will support them. In this phase, there must be an ability to see dependencies on hardware devices and ensure that the hardware targeted for deployment can satisfy this dependencies. During analysis phase, effects of the external devices on behavior of software components must be taken into consideration. Finally, during synthesis phase, we must take care that the code generated for software components reflects the platform's specifics of communicating with external devices. As reuse of once developed components is one of key concepts of CBD, we also need to make sure that components that are dependent on hardware can be deployed on different platforms that handle hardware devices in different manner. 2

4 The goal of the research is to investigate different possibilities for incorporating external devices into component models for embedded systems and construct an approach that would significantly advance how these component models handle external devices. This would include: enabling software components to specify their dependencies on external hardware devices, allowing these devices to be specified on different levels of abstraction (npr. Hardware pins, ports, drivers, services), providing a way for software components dependent on external devices to be handled as all other software components, enabling software components to be configured to reflect communication parameters for specific external devices, providing a way for semantics and extra-functional properties that can be defined for an external device to be used within a component model. 2.Research methodology As a part of the work, I have already studied a number of different component models, and as a result of this study I have written a technical report with a number of my colleagues which covers 22 components currently used in industry or research. I have also written a paper that presents a component model and technology that enables hardware and software cooperation using UPnP protocol. This paper was first accepted at the SERPS'08 conference, and later at the SEAA'09 conference. Future work would be mainly done in the frame of two different projects: PROGRESS project that is run on Mälardalen university (MdH), Västerås, Sweden, and DICES project that is run in cooperation on both Mälardalen university and Faculty of electrical engineering and computing (FER), Zagreb, Croatia. My work on PROGRESS project will be based on ProCom component model developed at MdH. ProCom component model is aimed for development of software systems for automotive embedded systems. I will investigate how to include sensors and actuators in the ProCom component model. DICES project aims to improve the ability to develop distributed embedded component-based systems. In scope of this project I will do research on how to enable cooperation of distributed software components with various hardware devices/components. 3

5 3.Central literature An comprehensive overview of the field is given in the book "Component-Based Software Development for Embedded Systems An Overview of Current Research Trends" by Atkinson, Bunse, Gross and Pepper [10]. Component-based approach in the embedded system domain is also covered in the book "Building reliable Component-Based Software Systems" written by Crnković and Larsson [11]. 4.Related work In this section I will state some of the technologies and approaches used in research, but also in practice, that is relevant to my work. In the first subsection I will give an short overview of some of the component models aimed for the embedded system domain. Focus on this overview is how they manage the dependencies on external devices. Second subsection gives an overview of languages and technologies that enable description of hardware devices. Some of the technologies listed also provide middleware capabilities,meaning that they enable communication with devices in a more abstract level which is more appropriate for higher-level software. Because the aim of my work is not to devise a new and revolutionary way for device description, but mainly interconnect a hardware description with modern and advanced component model for embedded systems, in my research I mostly considered hardware description technologies used in practice today Component models AUTOSAR [1], [2] is a new standardized architecture created by a partnership of a number of automotive manufacturers and suppliers with a goal to manage increasing complexity of vehicular embedded systems, enable detection of errors in early design phase and improve flexibility, scalability, quality and reliability of such systems. To achieve this, AUTOSAR applies component based approach for developing embedded systems. In AUTOSAR, underlying hardware that the system is deployed on is abstracted away by the AUTOSAR Runtime Environment that provides a platform-independent framework for the application layer. As a consequence, AUTOSAR applications can only be deployed on a hardware device only if there is an existing AUTOSAR Runtime environment for this specific device. In the application layer dependencies on specific hardware is encapsulated in special type of components, sensor and actuator components. These components are dependent on a specific sensor or actuator, but are independent of the hardware device that the application is deployed on. 4

6 COMDES-II [3] is a component-based software framework aimed for efficient development of reliable distributed embedded control systems with hard real-time requirements. COMDESS-II defines a two-layer component model, having the "upper" layer specify the behavior of a systems using active software artifacts called actors, while the "lower" layer defines the behavior of the actors using function block instances. Interaction of actors with the environment is encapsulated in input and output signal drivers. Drivers can be classified as either communication drivers (used to sense or actuate signals on a network), or physical drivers (used for sensing or actuating physical signals). Rubus component model [7], [8] was created by Articus Systems for development of dependable embedded real-time systems. Architectural elements of Rubus are software items, which can be either basic software circuits or assemblies or composites of other software items. Interfaces of software items are defined by input and output ports. They can be either used for exchanging data (data ports) or control signals (trigger ports). Behavior of a software circuit is defined by a C-language entry function. There are no special architectural elements that model external devices such as sensors and actuators. Instead, they are modeled by basic software circuits. Sensors are represented by software circuits that have no input data ports and at least one input trigger port, while actuators are modeled by software circuits that have no output data ports. Platform and device dependent information or behavior are hard-coded in the software circuit's C entry function Hardware description languages and middleware technologies AADL (Architecture Analysis & Design Language) [9] is an Architectural Description Language (ADL) standardized by Society of Automotive Engineers (SAE). It is used to model both hardware and software architecture of embedded systems. Although AADL models consist of architectural elements called components, system development in AADL does not follow the component-based development paradigm. There are three categories of component abstractions in AADL: application software (threads, thread groups, processes, data, and subprograms), execution platform (processors, memory, devices, bus) and composite systems. During system composition, application software is bound to appropriate execution platform components. LabVIEW [12] is a graphical programming environment designed by National Instruments and mainly used to develop measurement and test systems. LabVIEW programs are developed by connecting functional entities named function blocks. They can be realized through written code, external DLL library or they can represent hardware devices. Integration of hardware devices is enabled through built-in libraries and device drivers. 5

7 OPC [4] is an industry standard for connecting embedded devices and software. It uses Microsoft's COM and DCOM technologies for communication between OPC servers (embedded devices) and OPC clients. OPC servers provide items that represent connections to data sources within the server. Items can further be organized in groups. OPC items can have a number of attributes that provide additional information associated with them. The architecture supports access to remote data by both synchronous and asynchronous messaging, event and alarm notification, and access to stored data. The OPC foundation is currently working on specification of a new architecture, the OPC Unified Architecture (OPC-UA). OPC-UA moves away from using COM and DCOM and defines a platform-independent communication standard that uses XML. UPnP (Universal Plug and Play) [5] is an open standard that provides means for discovery, description and cooperation of different devices using standard TCP/IP network protocols. UPnP devices can be realized using either hardware or software. UPnP devices can provide detailed description of themselves and services they provide using XML. For communication, UPnP leverages standard TCP/IP protocol, which allows UPnP to be used on existing computer networks. It supports both synchronous method calls and asynchronous publish-subscribe communication. VHDL [6] is one of the most known and widely spread Hardware Description Language (HDL). It is used for describing hardware interfaces and behavior. Specification of hardware is on a very low level data types of bits or bit vectors, and integer or real numbers. It has also no ability to define extra-functional properties of hardware. 5.Key conferences Although the research topic somewhat covers hardware, it is from software engineering viewpoint, so we are mainly targeting conferences that cover componentbased software engineering and software engineering in general. Amongst most prominent of these are: CBSE (Component-Based Software Engineering) Aim of this conference is to promote a science and technology foundation for achieving predictable quality in software systems through use of software component technology and its associated software engineering practices. EMSOFT (International Conference on Embedded Software) This conference brings together researchers and developers to advance the science, engineering and technology in embedded software development. 6

8 ESEC/FSE (European Software Engineering Conference and Foundations on Software Engineering Conference) Joint conferences that cover software engineering in general. ICSE (International Conference on Software Engineering) Is a premier forum for researcher to present and discuss the most recent innovations, trends, results, experiences and concerns in the field of software engineering. ICSR (International Conference on Software Reuse) The main goal of this conference is to present the advances and improvements within the software reuse domain. SEAA (Software Engineering and Advanced Applications) Conference that focuses on software engineering in general, and new, innovative and advanced software applications. 6.References [1] AUTOSAR Development Partnership, AUTOSAR Technical Overview, 2008 [2] Heinecke H., Damm W., Josko B., Metzner A., Kopetz H., Sangiovanni- Vincentelli A., Di Natale M., Software Components for Reliable Automotive Systems, Design, Automation and Test in Europe, 2008 [3] Ke Xu, Sierszecki Krzysztof, Angelov Christo, COMDES-II: A Component- Based Framework for Generative Development of Distributed Real-Time Control Systems, RTCSA '07: Proceedings of the 13th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications, 2007 [4] OPC Foundation,.OPC, OLE for Process Control,. Report v1.0, OPC Standards Collection, 1998, [5] UPnP Forum, UPnP Device Architecture 1.0, [6] D. Perry, VHDL. New York: McGraw-Hill, [7] Arcticus Systems, [8] Kaj Hänninen, Jukka Mäki-Turja, Mikael Nolin, Mats Lindberg, John Lundbäck, Kurt-Lennart Lundbäck, The Rubus Component Model for Resource Constrained Real-Time Systems, 3rd IEEE International Symposium on Industrial Embedded Systems,

9 [9] Feiler, P. H., Gluch, D., Hudak, J., "The Architecture Analysis & Design Language (AADL): An Introduction", Software Engineering Institute, Technical Note, CMU/SEI TN-011, Feb 2006 [10] Atkinson, C.; Bunse, C.; Gross, H.-G.; Peper, C., "Component-Based Software Development for Embedded Systems An Overview of Current Research Trends", Lecture Notes in Computer Science, November 2005 [11] Crnković Ivica, Larsson Magnus, "Building Reliable Component-Based Software Systems", Artech House Publishers, 2002 [12] National Instruments, LabVIEW, 8