Geographically Distributed Virtual Test Environmentsfor Distributed Embedded Control System using Model-based Design
Yukikazu Nakamoto Tadahiro Ito Kenji Yabuuchi
Tatsunori Osaki
Graduate School of Applied Informatics, University of Hyogo, Japan
OCTOPATH Corporation, Japan
Fujitsu Ten Limited, Japan
nakamoto AT ai.u-hyogo.ac.jp
Abstract
Embedded control systems such as automotive andavionics systems form large-scale distributed ones which
consist of numerous CPUs and devices, including plants and various hardware components. The complexity of such systems has increased for sophisticated control using numerous types of sensor data. Meanwhile, market pressures lead to reducing development periods for the large-scale distributed embedded control systems. A model-based design becomes popular to solve the above problems, especially automotive industries. In this paper, we describe a distributed virtual test environment based on the model based design. The key features are communication middle-ware to enable large-scale distributed test with integrating
the programs in geographically distributed sites and control program execution with models of multiple abstractionlevels in the model-based design.
1 Introduction
Embedded control systems such as automotive and avionics systems form large-scale distributed ones that consist of numerous CPUs and devices, including plants and various hardware components that are controlled and accessed by the CPUs. The complexity of such systems has increased for sophisticated, safe, and environment-free control using numerous types of sensor data, which are collected from various vehicle components and sent to computers through vehicle networks. Meanwhile, market pressures lead to reducing development periods for the largescale distributed embedded control systems. A model-based
design to solve the above problems has become popular, especially in automotive industries. In the model-based design, a control system is modeled with state space modeling in the control design methodology and represented as a block diagram. In the block diagram, a block corresponds to a numerical operator in the mathematical model including proportion, integral, derivative actions, which are needed in
the control system, and a solid line between blocks repre-sents a signal. MATLAB/Simulink supports the design ofthe control system with a wide variety of blocks that areuseful.
Another solution for the problems is the usage of var-ious simulators that have been used to test functional be-havior of the embedded control systems. In the test phase,any bugs that occurred in the design phase are detected, and fixing these bugs is expensive. To avoid this situation and to reduce the test time, it is very effective to test the func-tional behavior of the system design and software design
at a higher level when using the plant simulators. Sim-ulators for automotive system development include ECU (CPU) simulators as well as plant simulators that are con-trolled by the ECUs, such as those for engines and brakes. To test ECU software in the absence of actual vehicle com-ponents, a software-in-the-loop simulation (SILS) is used.The SILS consists of an ECU simulator and a plant simula-tor. A hardware-in-the-loop simulation (HILS), where ECU software is executed in an actual ECU while a plant is sim-ulated, is also used [3].
To develop large-scale distributed embedded control sys-tems with high dependability and productivity, we have de-veloped a virtual execution environment platform. We call our platform the functional integration simulation environ-ment (FISE). The purpose of the virtual execution environ-ment platform is to test functional behavior of the large-scale distributed embedded control system software. We described the requirements for the platform and the initial system designs of the platform [6]. We recently presented
the development status of a hybrid software execution en-vironment in the FISE, which integrates virtual and real software execution environments for large-scale distributed embedded control systems to test functional behavior of dis-tributed embedded control software in a more realistic envi-ronment [7, 8].
In this paper, we describe a distributed virtual test envi-ronment using the model-based design, extending our pre-vious work. The key features are communication middle-ware to enable large-scale distributed testing with integrat-ing the programs in geographically distributed sites and
control program execution with models of multiple abstrac-tion levels in the model-based design.
Our contributions in this paper provide the followingbenefits to developers:
*From the control program viewpoint, a developer can test a control program without actual plants such as
controlled hardware and their environments.
*From the control design viewpoint, a control designer can test a control algorithm that is implemented in an
ECU program.
We introduce control system design briefly in Sec. 2.
Section 3 describes the geographically distributed virtual
test environment. Section 4 concludes the paper.
2 Control System Design
We describe the steps required to develop the control sys-tem in embedded control systems and briefly how to design
control systems using automotive systems as an example.
.1. Requirement Specification:
Requirements for an embedded control system in-cluding functional features and non-functional features
such as control performance are specified.
2. Architecture Design:
In this step, we design the architecture of an embedded control system. In terms of control design, we model
control functionalities of the system based on mathe-matical methods or the system identification method.
Next, we design the control system based on the block diagram model to specify continuous time behavior.
A control system, which consists of plants and con-trollers, is modeled with a state space modeling in the control design methodology and represented as a block diagram, where one block corresponds to a numerical operator in the mathematical model including propor-tion, integral, derivative actions which need in con-trol and a solid line between blocks represents a sig-nal. In this step, MATLAB/Simulink is used to model the control design. MATLAB/Simulink supports the design of the control system with a wide variety of blocks that are useful in designing control systems. The MATLAB/Simulink controller model is simulated
with a sampling cycle from the viewpoint of control performance, controllability, observability, and stabil-ity. Figure 1 shows a MATLAB/Simulink model of an anti-lock brake system [4].
3. ECU/Hardware/Software Design:
An embedded control system design is divided into ECU, hardware, and software components, and each
component is designed separately. The plants are an engine and brakes in an automotive system. Controllers are ECUs which obtain the inputs and statuses of plants through sensors and then output
commands to the plants through actuators. The con-troller part is implemented primarily with ECU soft-ware. Recently, it has become more common to design the software using a modeling language such as UML. The model is designed in the described time behav-ior while the control system is designed in continuous time.
4. Implementation:
The divided ECU, hardware, and software parts are im-plemented.
3 Functionalities of geographically dis-tributed virtual test environment
To integrate and test control programs in geographically distributed sites and control program execution with mod-els of multiple abstraction levels in the model-based design,
various simulators such as CPU simulators and plant sim-ulators should be integrated into the network and provide network-wide simulation functionalities in the large-scale distributed embedded control systems. The architecture for the distributed virtual test environment is shown in Fig. 2.
Communication middleware:
Communication middle-ware requires an open standardized interface. Various simu-lators such as CPU simulators and plant simulators are con-nected to the communication middleware. For this connec-tion to be established easily, the interface of the middleware should be open and standardized. We utilized open source
CORBA implementation, MICO, in the early stage of the development. CPU and plant simulators are executed as CORBA objects, and they communicate using the CORBA communication mechanism[7].
However, communication middleware in the distributed test environment should be established through the Inter-net. The background of this requirement is numerous ECU and plant developers exist, especially in the automotive in-dustry, and control software that they develop needs to be integrated. However, the control software, especially in the developing phase, is often prohibited to deliver control programs in a source code form from outside their sites,so the integration requires using the Internet. Thus, weadopted the windows communication foundation (WCF) inthe current implementation[1]. The WCF was introduced
as a communication subsystem in the .NET framework forservice-oriented applications. A service on top of the WCF (WCF service) provides operations. Invoking an operation in a service is implemented by SOAP over TCP or SOAP over HTTP. SOAP over HTTP in the WCF is necessary be-cause of testing in the geographically distributed sites. The merit is that application software on top of the WCF is in-dependent the lower layer network protocol, whether in the LAN or through the Internet. The drawback was that
the WCF is only used in Windows; however, the WCF will be available on Linux developed by the mono project[5].Control program execution including CPU simulators andmplant simulators are implemented as WCF services, whichmare collectively called simulation services in this paper. Am simulation service provides operations, which are invoked by other simulation services. We have evaluated the WCF
in the LAN setting by transmitting small-sized data. The result shows that these speeds are comparable to method in-vocation in MICO.
Multiple types of control software execution:
We pro-vide three types of control software execution with models of multiple abstraction levels at present. The first is a con-troller model in the block diagram. The second is nativeprogram execution, and the last is CPU simulation.
In native program execution, a user can test a newly de-veloped control program that does not require the other tar-get machine dependent functionalities. This is suitable formtesting a newly developed control algorithm. Whether themcontrol behavior in the algorithm is equivalent to the con-troller design with MATLAB/Simulink is checked. Testing source programs means testing ones in the platform inde-pendent model in the model-driven architecture[2].
A CPU simulator is necessary for testing not only newly developed software in an execution environment close to a real setting but also for existing software. The CPU sim-ulator is also helpful because performing tests without the source code is very helpful for software developers because only binary codes are delivered and all the source codes are not delivered in the industry.
Simulation speed is an important issue in a CPU sim-ulator. Interpretive simulators, which are widely used for debugging software, and cycle-accurate simulators, which are used in hardware-software co-design, are slow to de-bug and test software in a CPU. To solve the problem, we developed a translation-based CPU simulator using QEMU [7, 8]. QEMU is a virtual execution environment generator.
The CPU simulator, which is generated by QEMU, trans-lates the target machine code into host machine code and ex-ecutes it. We developed the V850 QEMU utilizing QEMU 0.13.0. A Dhrystone MIPS of V850 QEMU has been cal-culated as approximately 110.5 MIPS with the current PC with a standard clock speed. This simulation speed is suffi-cient for developing control software in the mid-range ECU in a few years.
Service adaption layer:
We prepared the service adap-tion layer on the top of WCF to control simulators as WCF services. The following functions are in the application pro-gramming interface (API) of the layer.
ReadDatareads 32-bit data from a port in a simula-tion service.
WriteDatawrites 32-bit data to a port in a simula-tion service.
callFuncinvokes a function invokes in a simulation service.
We assumed that the specified function could be exe-cuted independently of the other program execution.
SuspendSimsuspends the specified simulation ser-vice.
ResumeSimresumes the specified simulation service.
We can use these APIs as follows.
WriteDataemulates data arrival from plant services
andcallFuncemulates calling an interrupt handler
from the data arrival, respectively. The plant service
obtains data or a command from the controller with
ReadData.
WriteDataemulates data arrival from plant services
andcallFuncemulates calling a control algorithm.
The plant service obtains data or a command from the
control algorithm withReadData.
The last two APIs control program execution engines,
CPU simulators, and plant simulators.
Execution controller:
A simulation controller controls the simulation by executing the simulators cyclically. The
simulators perform the execution and are suspended af-ter that in simulation cycles in virtual time. An execu-tion controller resumes the simulators periodically and syn-chronously for some specific duration.
4 Conclusion
We described a distributed virtual test environment using the model-based design. The key feature is communication middleware to enable large-scale distributed testing with in-tegrating the programs in geographically distributed sites.
The testing environment provides different types of control software execution with models of multiple abstraction lev-els for testing from a source form as a platform independent model to binary form control programs.
Currently, we have developed a platform of the virtual test environment. In the next step, we are going to build ac-tual simulator services for the environments and test actual control programs using the simulator services to examine the effectiveness of the virtual test environment.
Acknowledgments
This work has been supported in part by a Scientific Re-search Grant-in-Aid from the Japan Society for the Promo-tion of Science ((C)21500040) and Fujitsu Ten Limited.
References
[1] David Chappell. Introducing Windows CommunicationFoun-dation, 2010.
[2] D. S. Frankel. Model Driven Architecture: Applying MDA to
Enterprise Computing. Wiley, 2003.
[3] R. Isermann, J. Schaffnita, and S. Sinsel. Hardware-in-the-loop simulation for the design and testing of engine control
systems. Control Engineering Practice, 7(5):643–653, May
1999.
[4] Mathworks. Modeling an Anti-Lock Braking System, 2010.
http://www.mathworks.com/products/simulink/demos.html
?file=/products/demos/shipping/simulink/sldemoabsbrake.html.
[5] mono project. Wcf development, 2010. http://www.mono-project.com/WCFDevelopment.
[6] Y. Nakamoto, I. Abe, T. Osaki, H. Terada, and Y. Moriyama.
Toward Integrated Virtual Execution Platform for Large-scale
Distributed Embedded Systems. InProc. 6th IFIP WG 10.2
International Workshop, Software Technologies for Embed-ded and Ubiquitous Systems, pages 317–322, Oct. 2008.
[7] Y. Nakamoto, K. Yabuuchi, T. Osaki, T. Kishida, T. Hara,
I. Abe, and A. Kitamura. Proposing a hybrid soft-ware execution environment for distributed embedded sys-tems. In Proc. 13th IEEE International Symposium on
Object/Component/Service-Oriented Real-Time Distributed
Computing Workshops, pages 176–183, 2010.
[8] Y. Nakamoto, K. Yabuuchi, and T. Osaki. Virtual soft-ware execution environments for distributed embedded con-trol systems. In Proc. 14th IEEE International Sympo-sium on Object/Component/Service-Oriented Real-Time Dis-tributed Computing Workshops, pages 288–296, 2011.
No comments:
Post a Comment