 | Level: Introductory Kane Scarlett (kane@us.ibm.com), developerWorks Editor, IBM
03 Jan 2007 Volvo's Dr. Cecilia Ekelin discusses the DySCAS consortium project and its quest to construct an architecture dedicated to enabling automotive electronics to form autonomous, ad hoc networks.
Cecilia Ekelin, who holds a Ph.D. degree in Computer Engineering and Computer Systems
Engineering, has been a research scientist at Volvo Technology Corporation,
Göteborg, Sweden since 2004. Her principal research interest is the field of
embedded safety-critical real-time systems. Dr. Ekelin is also the lead coordinator for
the DySCAS project (Dynamically Self-Configuring Automotive Systems), a research project
funded by the European Commission with a goal of elaboration of fundamental concepts and
architectural guidelines, as well as methods and tools, for the development of
self-configurable systems in the context of embedded vehicle electronic systems; she is
also a contributor to the paper "A Future Dynamically Reconfigurable Automotive Software
System" which developerWorks reviewed in a
previous article.
developerWorks caught up with Dr. Ekelin to ask her a few questions about the DySCAS project.
developerWorks: Describe your experience and what you'll be doing in the project.
Dr. Ekelin: I have previously worked in different European research projects on
software architectures for automotive vehicles. Since the projects have different goals,
the architectures focus on different aspects. In the end, the different architecture views must fit together since they should go into the same vehicle, so it is important to have collaboration between the projects. Therefore, DySCAS will look a lot at other projects such as AUTOSAR and ATESST to ensure that our results will be applicable.
My main task is to coordinate the project, but I will also participate in the work to define system requirements, such as which functionalities the system should support.
|
DySCAS consortium experience
Consortium members define the spectrum of disciplines needed to successfully implement the project. Project manager Volvo Technology AB contributes expertise in the fields of engineering, natural behavioral science, and social science with respect to the needs of the automotive industry. DaimlerChrysler AG manages the challenges posed by increasing system complexity by developing and transferring standardized architectures and interfaces. Robert Bosch GmbH delivers knowledge in the area of system integration of complex networked automotive systems. ENEA's role is to design the overall system architecture. The University of Greenwich offers experience in autonomic and self-managing systems. The University of Paderborn offers it in the fields of distributed and real-time systems, QoS-oriented design, and methods for networks and embedded end-devices. KTH brings systems engineering and development of embedded control systems to the table. Systemite brings advanced configuration tools and technology. Movimento provides access to the latest test systems for in-vehicle networks and infotainment platform diagnostics technology.
|
|
dW: Describe Volvo's role as "project manager." How will that work? What is the approach? What are the most crucial steps in the process and why are they crucial?
Ekelin: The project is structured into a number of work packages, which focus on different steps in the development. The outcome of each work package is a number of deliverables [that] contain the results -- these deliverables are reviewed by the European Commission every year to assess the quality of the project.
The role is actually "project coordinator," which means making sure that the work packages are aligned and cooperate. The work package leaders are responsible for the technical content. Administrative issues and public relations -- managing the contact with the European Commission, monitoring resources spent and results achieved, ensuring proper dissemination of project results, maintaining the DySCAS Web site -- will also be handled by the coordinator.
Since it is the EC that is our "customer," the most important phases are the annual reviews performed by the EC to ensure that we make progress and have interesting results. Or the project funding might be cancelled. Otherwise, I would say that the crucial part is to be able to show that our results are not only technically feasible but also economically beneficial for an OEM or supplier.
dW: I understand how Volvo's experience in automotive engineering applies to the project. Where does the company's experience in natural behavioral science and social science fit?
Ekelin: It doesn't really since we are not considering how the driver experiences the system -- except that it should be invisible -- or the social impact of the project.
dW: Can you provide a few hypothetical examples of the basic mechanisms and concepts for the dynamic reconfiguration of systems the project plans to develop or adapt?
Ekelin: It's a bit early to tell since at the moment we are working on a state-of-the-art report [that] will include a gap analysis. One expected adaptation of many existing services such as communication and scheduling is the ability to guarantee a certain quality-of-service level. New mechanisms needed are different "managers" to ensure that the requested reconfiguration is safe to perform; for instance, the resource manager has to ask if there are available resources to use, the configuration manager has to ascertain [if] the various components are compatible, the certification manager has to determine if the software is authorized.
dW: Talk a little about the tool chain to be used for the design and development and how it will support these new and adapted mechanisms.
Ekelin: So far we have no final decision on this, but it is likely that UML and possibly Enterprise Architect will be used for the design work. The resulting architecture will be specified using an ADL (Architecture Description Language), probably based on EAST-ADL or ATESST ADL. Simulations of architecture features will also be performed using something like Simulink and relevant toolboxes. Since the time and money associated with the project is not enough to make a full implementation of the DySCAS architecture, the implementation of the reference architecture and demonstrator applications may have to be based on existing technologies (such as Java), although these may not fulfill all the requirements.
dW: Explain the architectural patterns for a layered software architecture and how they will support "self" behaviors and context-awareness.
Ekelin: Again, it's just too early to say what the layers will include. Ask me again in six months.
dW: What kind of testing and analysis tools and techniques will the project employ to assure the implementations are going smoothly?
Ekelin: Since the implementation work has not started yet, it's too early to say. It is possible that code-generation supported by the modeling tools (like Simulink) could be one way to reduce implementation problems.
dW: Now, a fun question. Give me your most exciting idea of a real-world use case. Where are some areas that the project isn't tasked to go but the architecture could take it?
Ekelin: What is exciting for a researcher may not be so exciting for an end-user ... many of our use cases will not be visible to the driver, especially those dealing with resource optimization and fault tolerance, although these are probably the most challenging, and hence exciting, use cases to implement. For the driver, the ability to integrate the car with the external environment is probably more exciting. Like being able to download navigation coordinates from the Internet via a mobile phone.
The architecture and its services will probably be deployed for non-critical domains first, such as telematics, infotainment, and body/comfort electronics. If the architecture is successful in these domains, it could possibly also be used for high-integrity domains such as the chassis. The ability to perform reconfiguration such as in the case of a malfunction would actually be more important for this kind of domain. Before we get to this point, though, it would of course require extensive validation and verification of the architecture first.
dW: Thank you very much for your time. We would like to check back over time to see how the reference implementation is progressing.
Ekelin: It would be my pleasure.
Resources Learn
-
"Toward
autonomous automotives" (developerWorks, December 2006): This article takes a
detailed look at the Dynamically Self-Configuring Automotive Systems project's plans for
a specification to make automobile systems more autonomous. Its first product is a whitepaper that outlines some of the project members' objectives to advance the technologies required to build self-configuration aspects into automotive middleware layers and run-time environments.
-
The AUTOSAR development partnership (Automotive Open System Architecture) is an open and standardized automotive software architecture jointly developed by automobile manufacturers, suppliers, and tool developers to create innovative electronic systems that further improve performance, safety, and environmental friendliness.
-
ATESST:
The ATESST project (Advancing Traffic Efficiency and Safety through Software Technology)
is at the heart of a general approach to promote model-based software engineering that allows standardizing and automating design, integration, validation, and maintenance of the software embedded in high technology products.
-
"An Overview
of the Systems Modeling Language for product and systems development, Part 3: Modeling
system behavior" (developerWorks, October 2006): This article explains how SysML can be used to model the operating behavior of an embedded system product, a Rain Sensing Wiper, for an automotive application.
-
developerWorks Autonomic computing zone: Visit the Autonomic computing zone to stay on the cutting edge of this exciting technological direction.
-
developerWorks technical events and webcasts: Stay current with the latest technology.
Get products and technologies
-
Download a version of the Build to Manage Toolkit for
Problem Determination, filled with your favorite autonomic computing technologies
like the Log and Trace Analyzer (for Eclipse, Portal, and Java™ Desktop,
with a version for Linux® and for Windows®); the Generic Log Adapter
Runtime and Rule Sets (for AIX®, Linux, OS/400®, Solaris, Windows); the Remote Agent Controller (for AIX-Windows); the LTA, GLA, and Eclipse in a single install package (Linux and Windows), and documentation.
-
IBM trial software: Build your next development project with trial software, available for download directly from developerWorks.
Discuss
About the author | 
| | Kane Scarlett is the editor of the Autonomic computing technology zone for developerWorks. His past publishing work was with such magazines as Unix Review, Advanced Systems, and the -World publications (Java-, Sun-, NC-, Linux-), as well as some little oddball journals like National Geographic Magazine. |
Rate this page
| |
