Universal Object-Oriented Modeling for Rapid Prototyping of Embedded Electronic Systems

M. Kuhl, B. Spitzer, K.D. Muller-Glaser Institute for Information Processing Technology

University of Karlsruhe Engesserstr. 5,76 13 1 Karlsruhe, GERMANY

{ kueh1;spitzer;kmg } @itiv.uni-karlsruhe.de

Abstract

In this paper a new approach f o r an overall system de- sign is presented. It supports object-oriented system model- ing f o r soflware components in embedded systems in addition to the well known time-discrete and time-continu- ous modeling concepts. Our approach supports structural and behavioral modeling with front-end tools and simulu- tion/emulation with back-end tools. The XMI (XML Metu- data Exchange) metamodel is used f o r storing CASE data to a commercial object repository and exchanging CASE datu. The CASE tool chain, presented in this paper, supports con- current engineering with versioning and configuration management. Finally we discuss the suitability of XMI f o r concurrent engineering using the Unified Modeling Lan- guage notation for an overall system design cycle.

1 Introduction

The design of complex electronic systems, especially of deep embedded systems, is characterized by a rapidly in- creasing complexity and shorter product cycles today. Key aspects of successful products are quality, functionality, and time-to-market.

A traditional design cycle is characterized by non-formal descriptions of requirements, long iterations and design re- sults which leads to misinterpretations. Therefore, the tradi- tional design cycle must be revised. Besides other forms of prototyping, the up-to-date approach of concept-oriented rapid prototyping is a technology which can be used to ad- dress the items mentioned above. Concept-oriented rapid prototyping defines a way for the fast conversion of an ex- ecutable specification, which captures the requirements, into a functional prototype. This prototype serves mainly for clarifying system goals and must support a widespread range of hardware interfaces. It uses automatic code ener- ation based on CASE' tools like MATLABBimulink , AS- 5

'Computer Aided Systems/Software Engineering *MATLAB/Simulink is registered trademark of Mathworks, Inc.

U. Dambacher Inst. for Machine Tools and Production Science

University of Karlsruhe 76 13 1 Karlsruhe, GERMANY

ulf.dambacher @mach.uni-karlsruhe.de

CET3 or Statemate4 and powerful, general purpose, extensible hardware (see fig. 1). The cost of rapid prototyp- ing hardware is not critical, because the hardware is not spe- cific and can be reused for different prototypes.

In a top-down system design approach two other levels of rapid prototyping are covered. In stage 2, the final archi- tecture of the system under development is fixed with archi- tecture-oriented rapid prototyping. A distinguishing mark of this stage is, that some of the system components are fi- nally shaped and tested while other components are still un- der development. In stage 3, implementation-oriented rapid prototyping is used for a final system optimization and test. Many of the involved system parts are close to the final re- lease, other system parts consists usually of far developed prototypes. At this level an accurate performance analysis is often possible.

Figure 1 : Scope of rapid prototyping

In this paper we focus on concept-oriented rapid proto- typing for the development of embedded electronic systems using our universal object-oriented modeling approach. Up to now concept-oriented rapid prototyping was influenced by tools for Computer-Aided Systems Engineering using the state chart theory (modeling of hierarchical state-ma-

3ASCET-SD is a registered trademark of ETAS GmbH. 4Statemate is a registered trademark of i-Logix, Inc.

1074-6OOYO1 $10.00 0 2001 IEEE 149

chines) or control systems engineering using block dia- grams. In the last years much effort was spent to improve design tools for an better integration of state charts (model- ing time-discrete behavior of embedded systems) and block diagrams (for modeling time-continuous behavior of con- trol systems).

Current requirements in embedded systems design shift the attention from a pure state chart and block diagram ap- proach to a more software-oriented view. One reason for this paradigm change can be found in system complexity, e.g. distributed embedded systems with network interfaces or auto diagnostic of complex embedded systems during system startup. In order to support the development of such software centric embedded systems, CASE tools have to follow a design methodology called object-oriented analy- sis and design using the Unified Modeling Language (UML) notation. A major problem common to all commer- cial software CASE tools is a lack of control systems engi- neering support whereas modeling of time-discrete or state- oriented systems is well supported. Therefore, modeling of mixed-domain systems with both time-discrete and time- continuous blocks and additional software components (e.g. auto diagnostic) is not a continuous design process today.

In order to support the development of an electronic sys- tem, a rapid prototyping system has to fulfil the following requirements:

Integration of different modeling techniques like state/ event modeling, control system design, and object-ori- ented analysis and design Overall system modelling, simulation, and emulation. Concurrent Engineering support with versioning. Target independent code generation. Powerful process visualization. In the following we will summarize the related work for

concept-oriented rapid prototyping (see Section 2). In Section 3 we will present our universal object-oriented modeling approach for embedded electronic systems. Af- terwards, a clientkerver CASE tool environment for con- current engineering is introduced (see Section 4). In Section 5 the underlying metamodel of our CASE tool en- vironment is presented, which uses widely concepts from XMI. Finally, section 6 discusses results and offers a con- clusion of the topic.

2 Related Work

Commercial solutions for object-oriented modeling of embedded electronic systems are rare. Today, a wide range of CASE tools for object-oriented analysis and design is available supporting mainly pure software modeling. Soft- ware CASE tools for embedded system modeling are often new to market. Only three well known CASE tools support either object-oriented analysis and design using UML nota-

tion and time-discrete modeling (e.g. state charts). Artisan Real-Time Studio, i-Logix Rhapsody, and Rational Rose Realtime are tools classified explicit for this domain.

A major drawback to this CASE tools is the lack of mod- eling concepts for control system engineering. For an over- all system design approach users will have to source-code include external C-code (build with e.g. Simulink or MA- TRIXx) into these CASE environments. This approach is expensive and very rigid. Communication between both modeling domains (software to time-discrete and time-con- tinuous system part) is often done by source code coupling. In large-scale systems, changing system architecture in the development process is very error prone. Therefore, model- based coupling of software components and time-discrete/ continuous system part is desirable.

3 Universal Object-Oriented Modeling

A typical design e.g. for a control unit in automotive ap- plications consists in general of a CAN' interface, a system controller, a time-continuous system part, and other compo- nents. In an object-oriented modeling approach using the Unified Modeling Language notation, the CAN interface or the central system controller can be modelled with classes or with objects in a more detailed notation (a class is a blue- print of an object in general). It is clear, many of the func- tionality provided by the CAN interface or the central system controller can be modelled using only state chart or time-discrete modeling. Using object-oriented analysis and design instead, system components can be modelled with classes. A major advantage of this approach is the visibility of component properties, operations, and a clear genealogy while using inheritance or generalization. This demand is obvious not only when reusing component from libraries in embedded system design. In figure 2 a class diagram pre- sents a basic configuration for a typical distributed control unit based on a CAN interface, a system controller and a message queue between both objects.

Figure 2: Basic Class Diagram for a Control Unit

'CAN = Controller Area Network

150

If we try to combine this class diagram with a time-con- tinuous subsystem (see figure 3; PTI control subsystem block) modelled by a so called hierarchical block diagrams (e.g. using the commercial CASE tool Simulink) no direct model linking between these different system domains is possible. A technique called source-level coupling is used to fulfil the needs for an overall system design approach in- stead. A major problem gets obvious: beside the graphical representation of an IN or an OUT port in the block diagram no information about how to access these ports from outside the block diagram can be added. If we try to change the sub- system variables 'k' and '7' from outside the block diagram (e.g. initiated by a CAN message, see figure 2), we have to add additional model information to the given block dia- gram (block defaults IN port).

Gain1

PTI-Subsystem

Figure 3: Using block diagrams for hierarchical, dynamic system modeling (e.g. PT1 controller).

In the following we will present a design methodology called universal object-oriented modeling. Using this ap- proach in an overall system design process, we can over- come the drawbacks mentioned before.

One of the most important requirements for a continuous design process is the use of model-based subsystem cou- pling instead of source-level coupling. To fulfil this require- ment, we have either to transform one modeling notation to another notation. With regard to object-oriented modeling for software components in embedded system design, it is obvious to transform time-continuous subsystems to an equivalent object-oriented representation.

For the PTZ example of figure 3 an equivalent object-ori- ented representation is shown in figure 4 from the class viewpoint. The class diagram is used as static model of the time-continuous subsystem block in this case and is reus- able for other subsystems. At this point adding of operations for simulation and code generation is rather simple but not in the focus of this paper.

I ::Block _________

port MockName

::lntegratot

f .

I

::Line ::Blanch i

Figure 4: Class diagram for time-continuous system modeling (simplified)

For dynamic modeling of the time-continuous system domain, the block diagram is analyzed and then trans- formed into an object collaboration diagram using the Uni- fied Modeling Language notation (see figure 5). Each model block in the block diagram is transformed into an equivalent object.

Figure 5: PTl subsystem transformed in an object collaboration diagram (simplified)

15 1

Two possible transformations for connections (line in the block diagram) are thinkable. First we could use an ob- ject association as defined in UML. Since we have to store more complex information than a simple name it is obvious to use an object from type Line for each connection. Con- nection which are linked to more than two blocks in the block diagram will be modelled with an additional Branch object for each link.

At this point we can integrate both modeling domains by using a dynamic object diagram representation for the over- all design of heterogeneous embedded systems. If we go back to the requirements of the control unit in figure 2, it be- comes clear, in which manner an access from outside of the time-continuous subsystem part can be managed. In the message sequence chart shown in figure 6, ControlUnitSC from type SystemControl sends a setGainValue message to Gain and Gain1 residing inside of the time-continuous sys- tem part (PTI subsystem). At the beginning, this sequence was initiated by an external actor Remote sending a CAN message to the CAN interface of the control unit.

Figure 6: Object sequence diagram: CAN mes- sage initiated property change in subsystem PTl (see also figure 3 and 5)

With the presented transformation guideline it is possi- ble to design a bidirectional transformation tool. From a block diagram representation an equivalent object diagram can be generated and vice versa. In the viewpoint of an uni- versal modeling approach for an overall system design, it is advisable to do the control system design in Simulink or MATRIXx. After this, the time-continuous model can be transformed into an equivalent object representation using forward engineering. Going back to a software CASE tool (e.g. Artisan Real-Time Studio) the time-continuous sub- system gets available as object diagram. From there, de- signers can use objects from the time-continuous domain in the same manner as they use objects from normal software components (e.g. SystemControl in figure 2).

Since the synchronization between both representations is dynamic, i t is possible to generate a Simulink or MA- TRIXx model from a different hierarchy layer (see figure 2 ) . This feature is with regard to concurrent engineering a need for todays system complexity.

4 ClienUServer Architecture for CASE

To keep the system model manageable for designers, CASE tool integration is necessary. In [ 1][2] an open design environment for the development of mechatronic systems based on CDIF was presented. Many of the experiences from this project influenced our current work.

After the design of prototypes in the last two years a so called virtual MetaToolSenter (Mts) is in the focus of our current work. The setup of the Mts follows a 3-tier architec- ture well known in the software engineering domain. On the lowest layer (database layer) we have chosen a commercial object repository called Enabler from Softlab [9]. In rhe meantime, Enabler is on market for about 15 years. Enabler comes with user authentication, transaction management, object versioning, and configuration management.

As a metamodel for managing CASE data, Mts uses the Unified Modeling Language metamodel. One of the main reasons for selecting this metamodel is its compatibility to the upcoming XMI (XML metadata interchange, see also section 5) standard from the OMG (Object Management Group). Actually, Mts uses uml.dtd as database scheme for storing object classes, attributes, operations, associations (e.g. generalization, aggregation), objects, packages, class and object diagrams (without graphical layout information). Inside the database layer an abstraction interface keeps Mts independent from the given database. To proof this concept we work also on an interface to the ORACLE object-reIa- tional database management system.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .n.. . . . . . . . . . . . . . . . . . . . . . .n.. . . . . . . . . . . ,

Figure 7: 3-tier architecture of the development environment (MetaTool-Server)

In the business layer of Mts the mediator pattern [ IO] is used to keep the CASE tool adaptor uniform and the CASE tool integration simply. XMI objects from the repository will be transformed in interim objects more common to the object and class diagram representation. While generating interim objects, the CASE adaptor (see class MtsTool in fig- ure 8) keeps thin and high reusable. Another reason for in- terim objects in the business layer is because of object identity to handle object versioning and configuration man-

152

agement. For example, an unique identification number is added to a subsystem block from the time-continuous sys- tem domain. After the block is checked out from the repos- itory, a designer moves this subsystem to another hierarchy layer. Still it is the same compound object, the system con- troller in the time-discrete system part keeps track of this link because of the subsystem identification number.

I ::MetaToolServer 1

I I I I I

1

Figure 8: Metatool Server Architecture - Classes

To keep the CASE tool integration simple, a CASE tool backend was introduced called GenerulStore (GS). This CASE tool backend encapsulates the business layer and some smaller parts of the presentation layer (mainly often used calculations for the graphical representation and per- sistence). Therefore, CS implements mainly the business layer of the virtual Mts architecture (see fig. 7). Actually, GS provides two CASE tool adapters (SimulinkmdP which is file-based and the COM' based Real-Time Studio rtsln- teguce). For model management and CASE tool control, GS offers a system hierarchy browser (see fig. 9). Since the internal representation of Mts architecture is done using a XMI conforming data model, GS offers a system browser for all XMI objects of the current design. Because of the big amount of XMI objects (for example: the transformed PTl subsystem needs about 10,000 XMI enitites), GS offers de- sign domain specific hierarchy browsers (e.g. a systemkub- system hierarchy view for structural or time-continuous design; a package hierarchy view for software design).

Actually, GenerulStore has two CASE tools in the pre- sentation layer. Artisans Real-Time Studio was selected be- cause of its object collaboration diagram presentation. In Artisan's Real-Time Studio attribute values of objects can

be visualized (e.g. see fig. 9). MATLAB/Simulink was se- lected for the control system design domain. Both CASE tools are bidirectional linked to the Mts architecture over a specific home interface in GeneralStore CASE backend.

Figure 9: GeneralStore with XMI and Simulink hierarchy

5 XML Metadata Interchange (XMI)

The main purpose of XMI is to enable easy interchange of metadata between modeling tools and metadata reposito- ries in distributed heterogeneous environments. XMI inte- grates three key industry standards:

XML - extensible Markup Language, a W3C standard. UML - Unified Modeling Language, an OMG model- ing standard. MOF - Meta Object Facility, an OMG metamodeling and metadata repository standard. Key aspects of XMI are the four layered metamodeling

architecture for general purpose manipulation of metadata in distributed object repositories and the use of the Unified Modeling language notation for representing models and metamodels which makes it suitable for our universal ob- ject-oriented modeling approach.

XMI was influenced in some way from the ideas for a tool-independent CASE data interchange format called CDIF which was based on entity-relationship (ER) descrip- tions. CDIF addresses the problem of model data inter- change between CASE tools. Without a standardized interchange format for integrating more than one CASE tool, an exchange of model data must be supported by pro-

'Microsoft Component Object Model

153

prietary import/export filters and for every tool integration new interfaces have to be implemented.

In the meanwhile, XMI is supported in a wide range of industry applications. Going to the machine tool domain for example, STEP, a standard for the exchange of product def- initiodmodel data, will be compatible in future to XMI.

In fig. 10 a typical scenario for a Gain block as part of the transformed time-continuous subsystem PTl (see exam- ple in section 3) is shown in a XMI object collaboration.

1 - 1 F C Classifier feature' F C Feature Owner ~

. . F C StructuralFeatdre typeZ F C = Foundation Core'

Figure 10: Gain block in XMI notation (simplified)

6 Conclusions

The introduced universal object-oriented modeling ap- proach supports the concurrent development of electronic systems in all design phases. We presented in which way heterogeneous system descriptions can work as integrated parts of an object repository based ClientlServer CASE tool environment. Based on a object collaboration diagram rep- resentation, time-continuous subsystems and software com- ponents can be modelled using one single description style. A direct linkage between different description domains is possible on an abstract model level. While transforming all subsystem parts to an uniform object notation, adding addi- tional model information to time-continuous blocks will en- able system designers to start with system simulation early in the design process.

An often needed feature and simultaneous a drawback of project file-based CASE tools (e.g. Rhapsody, Simulink) is the lack of support for CASE tool assisted concurrent engi- neering. Using the presented CASE tool backend GS with MATLAB/Simulink, an interim project file is created each time a designer checks out part of the model at a specific model hierarchy. The checked out subsystem hierarchy gets protected. Other designers have still read access to the last version of this subsystem and can get read/write access to other subsystem in the time-continuous system hierarchy.

One major drawback using MOF from XMI as a meta- model for system description is the lack of a standardized graphical representation for class and object diagrams. In the meanwhile this is one of the most requested topics for UML 2.0 and the next XMI generation. On the other side, using XMI or the UML metamodel for the description of embedded systems will enable model exchange with other CASE tools. Today, at least 10 software CASE tools on market can handle XMI descriptions from the information view point (import of model without graphical description).

Future work will focus on the definition of a tailored de- sign process and the integration of CASE tools for require- ments management (e.g. DOORS'). On the back-end side of our development environment simulation and emulation of system models will be supported by a so called real-time framework and specific code generation tools based on the uniform XMI system description. We will examine the in- tegration of further modeling tools to estimate the integra- tion effort saved using XMI. Especially for large systems of different design domains, our universal object-oriented modeling approach for the design of embedded electronic systems based on XMI will show it's superiority.

References A. Burst; M. Wolff; M. Kuhl; K.D. Muller-Glaser: A Rapid Prototyping Environment for the Concurrent Development of Mechatronic Systems, ECEC, Erlangen, Germany, 1998.

A. Burst; M. Wolff; M. Kuhl; K.D. Muller-Glaser: Using CDIF for Concept-Oriented Rapid Protogping of Electronic Systems, RSP, Leuven, Belgium, 1998.

EIA / CDIF Technical Committee: CDIF/CASE Data Inter- change Format. EIA Interim Std. EIS / IS- 106-1 12, 1994.

Object Management Group: OMG /XML Metadata Inter- change ( X M I ) Vl.O,2000.

B.P. Douglass: Doing Hard Time - Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns. Ad- dison-Wesley, 1999.

B.P. Douglass: Real-Time UML -Developing Efficient Ob- jects for Embedded Systems. Addison-Wesley, 1999.

M. Fowler: Refactoring - Improving the Design of Existing Code. Addison-Wesley, 1999.

M. Fowler; K. Scott: UML Distilled - Applying the Standard Object Modeling Language. Addison-Wesley, 1997.

Softlab; G. Merbeth: Enabler - Technical White Paper; Soft- lab, Germany, 1999.

[ I O ] E. Gamma et al.: Design Patterns - elements of reusable ob- ject-oriented software; Addison-Wesley, 1994.

~

'DOORS IS registered trademark of Quality System & Software, Inc

154