Home

INSTITUT F¨UR INFORMATIK CASE Tools for Embedded Systems

1. SEOS HOR 6 tea Figure 11 3 Sequence Diagram gt From the use case description you can derive a sequence diagrams see Figure 11 3 These diagrams describe the interaction of the user with the system Sequence diagrams can also be used later during system design for describing the interaction of the components with each other Therefore you place some components on the diagram and along their lifelines messages or function calls can be drawn from a component to another Timers can be used for visualizing time con straints There are functions for referencing and decomposing avail able in order to reuse other diagrams or to make them more readable The next notation to mention is the class diagram see Figure 11 4 Here it is possible to specify all classes of the system their attributes Class Diagram Klasse Klasse2 Figure 11 4 Class Diagram and their methods Furthermore signals and interfaces consisting of 11 2 MODELING THE SYSTEM 205 a group of signals can be defined The classes can be linked with as sociation generalization and aggregation lines The classes can also be given ports and one can specify which signals and interfaces these ports support see Figure 11 5 Furthermore the direction of the sig lt lt signal gt gt B_LOW_SITZ lt lt signal gt gt BattTB Integer
2. tsinternport TS Tuerschliesser Figure 11 18 Internal Communication 11 5 3 Design of the behavior Allthe functionality is in the main class and its three containing core classes The behavior of these classes is completely specified by the 44 state chart diagrams As an simple example a state chart diagram of the Benutzer management class will show what happens when the driver saves his 226 CHAPTER 11 TELELOGIC TAU seat position see figure 11 19 He presses the set button what creates the MGMT_SET set MGMTSETtimer now 0 1 settaste_gedrueckt y y y y i MGMT 1 MGMT 2 MGMT 3 MGMT 4 MGMTSETtimer Solll HOR Soll2 HOR Soll3_HOR Soll4_HOR Ist_HOR Ist_HOR Ist_HOR Ist_HOR Solll_W Sol1l12_W Soll3 W Soll4 W Ist W Ist W Ist W Ist W solii s Soll2 S Soli3us Soll4_S Ist_S Ist_S Ist_S Ist_S Solll_V soll2_v Soll3 Vv Soll4_V Ist_V Ist_V Ist_V Ist_V So111_H Soll2_H Soll3 H Soll4 H Ist H Ist H EsE_H Ist_H C C93 C93 09 Figure 11 19 Example for a state chart diagram signal MGMT SET signal that is received by the class in the begin state A timer makes sure that the system goes back to the begin state if it button is released see rightmost branch of the diagram However if at the same time one of the four position buttons MGMT_x is pressed the stored val ues of the seat positi
3. Module 3 Module 1 Module 2 p state machine Figure 6 12 Structure of the project Module 2 The second module contains also only one single class which is implemented as a state machine This state machine realises the centralized door locking We thought that the properties of a state machine are perfect to solve the door locking problem The state machine is made up of a start state an error correction state and a hierarchical state see Fig 6 13 on page 92 In the hier archical state the needed operations to lock and unlock the door are realised Therefore are used also hierarchical states The conditions and actions needed are implemented in ESDL code ESDL is quite a simple programming language developed by ETAS its syntax is sim ilar to C and Java hierarchical state swich to door locked or door unlocked c door is concurrent open and locked signal to unlock the door sequence of states a Figure 6 13 Structure of the state machine The specification of the centralised door locking requires the use of a timer component to realise several delays during the runtime This timer component is implemented as a block diagram and assigned to different actions of various states 6 5 MODEL OF THE CONTROLLER 93 Module 3 The third and last of our modules is the most complex one In contrast to the other two modules it contains two classes One of these two classes implements t
4. 10 1 General Aspects Rose RealTime is a software development environment tailored to the de mands of real time software Developers use Rose RealTime to create mod els of the software system based on the Unified Modeling Language con structs to generate the implementation code compile then run and debug the application Functionalities Rose RealTime includes features for 1 creating UML models using the elements and diagrams defined in the UML 2 generating complete code implementations applications for those models 3 executing testing and debugging models at the modeling lan guage level using visual observation tools 4 using Change Management systems for team development we did not use this feature for modelling the TSG case study Development phases Rose RealTime can be used through all phases of the software development lifecycle from initial requirements anal ysis through design implementation test and final deployment It provides a single interface for model based development that inte grates with other tools required during the different phases of devel opment For example developers work directly through Rose Real Time to generate and compile the code that implements the model 179 180 CHAPTER 10 RATIONAL ROSE REALTIME Documentation The documentation of the tool functionalities is very good Using the documentation map from the online documentation you can find quickly the information you need
5. 3 2 MODELING THE SYSTEM 31 a message until the message is accepted by the receiver With message asynchronous communication the sender of a message is not influ enced by the receiver of the message the receiver will always accept the message This is either the case with buffered communication where the receiver buffers unread message until consumption or with signal based communication where unread messages are overwritten by new arriving messages Time Synchronization This form described the synchronization of the actions of different components In event driven systems behavior is triggered by the occurrence of events in time driven systems behav ior is triggered by the passing of time The applied tools use different combinations of those synchronization as pects Artisan Method based event driven Artisan uses a method based com munication model The exact interpretation of the method call mes sage asynchronous or message synchronous is left open and depends on the implementation platform Since objects are activated by com munication events the model operates in an event based fashion ASCET SD Signal based time driven ASCET SD uses a signal based com munication Time synchronization usually is performed time driven with individual rates for the components additionally there are some predefined events like interrupts AutoFocus Signal based time synchronized event driven AutoFOCUS uses a signal based
6. Available Description Techniques Applied Description Techniques Complexity of Description A 4 van ce e eed Modeling Interaction 22 209 22 ERR 82 82 84 84 84 86 88 89 90 91 91 95 100 101 101 102 102 104 105 106 107 107 108 110 112 112 113 114 118 119 120 120 120 121 121 10 CONTENTS 8 3 Development Process zur ars Iren Se Oe edes 130 8 3 1 Applied Process o ces ten Ma EH A 130 8 3 2 Applied Process Support 2 4542 Bs SEA 131 8 3 3 Applied Quality Management 132 8 3 4 Incremental Development 134 84 Conclusion 2 0 0 0 0 2 135 85 Model of the Controller 2 2222222 136 8 5 Overview sd 2 000 en Sep sees eat pre une 136 8 5 2 Components and their Functionality 136 8 59 Teste y sn me ee a Ba Zee 149 86 Appendix Faults in the specification 153 Rhapsody in MicroC 155 91 General Aspects se au Verrat 155 9 2 Modelling the System oor AG Era une 158 9 2 1 Available Description Techniques 158 9 22 Applied Description Techniques 163 9 2 3 Complexity of Description 2 22 fp UR mg 163 92 4 Modelling Interaction 0 164 9 3 Development Process e coe LI erm dela ee Bes 165 9 3 1 Applied Process us 22 shes Di alee a 165 932 Applied Process Supports ss san XS 165 9 3 3 Applied Quality Management 167 9 3 4 Applied Target Platfo
7. Requirements tracing MATLAB itself provides no functionality to trace requirements but there exists an add on called Requirements Man agement Interface that enables the user to interface MATLAB with formal requirements management systems like DOORS or Microsoft Word and Excel as well as with HTML documents This tool gives you the possibility to associate requirements with Simulink models and Stateflow diagrams 8 3 4 Incremental Development Reuse The reuse factor in the model for the centralized door locking was not very big because the two actions locking and unlocking are dif ferent While modeling the manual seat adjustment and the user management we were able to reuse a lot of components as each axis of adjustment requires the same control flow and thus only names 8 4 CONCLUSION 135 and values but not the complete structure had to be changed Dur ing this changes Stateflow s click and drag approach and its good search and replace functionality helped us in a good way Restricted changes As we created our model in a modular way we could restrict the changes to be made to the according module and just had to change some transition annotations and state names which could easily be done with Stateflow s search and replace function and had to add some variables Modular design Stateflow did not support us in finding a modular design so we had to make this step by ourselves as described above Restructuring The
8. Sitzverstellung zun chst nur f r die zwei Verstellachsen Winkel Lehne und Abstand Sitz Lenkrad realisiert Erst nachdem diese Funktionalit t vollst ndig ausf hrbar im Werkzeug simuliert und getestet wurde werden die Funktionalitaten f r die Verstellung der drei weiteren Achsen hinzugef gt 6 2 Umgebung Um ein ausf hrbares Modell f r die Simulation zu erhalten ist in bestimmten Fallen die Modellierung der Systemumgebung des T rsteuerger ts notwendig und sinnvoll Ein vereinfachtes Modell der Umgebung sollte daher Bestandteil der Modellierung sein Wichtig ist dabei dass die Grenze zwischen System und Umgebung klar ist Ein Beispiel f r ein solches Umgebungsmodell ist die Modellierung der Umgebung der Sitzverstellungsfunktion in Form eines Verstellmotors und eines Positionssensors Wird der Verstellmotor durch ein Signal der Steuerung in eine bestimmte Richtung gefahren erwartet die Sitzverstellungsfunktion eine R ckmeldung in Form eines Positionssignals Die Umgebung sollte dabei in Form von m glichst einfachen Dummies abstrahiert werden d h es werden nur diejenigen R ckkopplungen erzeugt die f r das Funktionieren des Simulationsmodells notwendig sind 6 3 Abstraktionen f r Hardware und Bus Kommunikation Ein Modell eines Systems ist immer auch eine Abstraktion d h eine durch gezieltes Weglassen entstandene Vereinfachung In den folgenden Abschnitten wird diskutiert wie HW und Bus Kommunikation t
9. an was au ET r LE i 5 E 1 044d5 L KLEE ak opip BL A4 Vat H JE oia M ea aNEd 11 an za Dy Less Jorn aa Bla IME VSPA a CHAPTER 5 TOOL ARTISAN REALTIME STUDIO Figure 5 3 Part of an exemplary sequence diagram i 7 o e 2 gt 8 192 9x0 12324 uo 23g pu3 uonsag pu3 UONDSBS pu3 uo 23 95 pu3 gas BOW Z volayulsau us p Uu0nawuisauifjug e8 aspuayw ZUS MOT B eGessaui Nyo pas uonda3x3 awig L ZUS MOT B wonda Ixa vo ADL gt a epoa NNEGA sGessau NYO anasa eyo Mayeq pO melang aey Aalen HI N3340 1990 N 9211 abessaw YOLOSNNOD anaJay snjejs uado mop BH adang snes uado sop 335 eO essau NYI ANIH Apopa BO Sieg AIBA BO aspa wauaww s dois paseap ajep uo J yuasa uoma afiveyd uona ajeflojag pajaajap suey uona 68 uojpg Bumon sod jeas e saseaasassald Jau p eur I mo eam a Beare uonduasag 5 5 MODEL OF THE CONTROLLER Figure 5 4 Class Diagram Cortnollereehl logi rana pha arr cits geh ent 69 70 CHAPTER 5 TOOL ARTISAN REALTIME STUDIO commute a physical signal into an use case invocation there are more com plex classes like the seat or the environment The environment composes all external functions related to the can bus Additionaly to the signal for warding the door and seat classes implement elaborted tasks For example adjusting the seat is realized by instantiating a thread which watches the s
10. seat adjustment has to stop its work and restart immediately with the new parameters In addition to these features there are some 6 5 MODEL OF THE CONTROLLER 95 more requirements imposed by the specification that should be con sidered velocity of the vehicle tension of the battery front door open or close For checking them there are used very simple classes not really worthy of mention 6 5 2 Functionality In the previous item the structure of our model is described now we give a description of the functionality of these components Project The job of the project is to connect the realised modules It al lows to define tasks and thereby to simulate the real time behavior of the whole problem The modules user management seat adjust ment and centralised door locking generate CAN messages while they are working These messages have to be processed by the CAN connection So a connection between these modules is necessary Be tween the modules user management seat adjustment and cen tralised door locking there is no connection These components are independent from each other see Fig 6 12 on page 92 CAN connection The CAN connection is realised by a C code file ACAN message is made up of nine fields the first field contains the message identifier the second field contains the message content and the re maining fields have not been considered for the implementation On the basis of this we used an array wi
11. 12 3 2 Applied Process Support Simple development operations The Trice tool supports effective devel opment operations with its graphical editors and basic features like online help unlimited undo redo drag and drop copy paste Spe cial features of classes actors protocols data include drag and drop cut and paste and an easy access to the editing possibilities The drag and drop cut and paste are very similar and the main idea is that actors may be copied onto a file or into another trice application When copied into a file a file named like the dropped class will be created with the extension tdc tpc or tac depending on the type of the dropped class Cut copy paste and merge features also exist within the behaviour editor When applied states are copied with all their substates and subtransitions Carefull by dragging and dropping as further changes and adjustments have to be made manually 12 3 DEVELOPMENT PROCESS 233 Another useful feature is the possibility to create a documentation for each actor When creating documentation of the main actor system the documentation describing the whole project structure and behav ior will be created into a previously defined html file Complex development operations Trice supports deployment on hetero geneous hardware components Scheduling of tasks in the generated applications can be configured for each active object on each target in the distributed application separ
12. 164 CHAPTER 9 RHAPSODY IN MICROC the label on a transition in the state charts differs from 7 to 476 characters in every view Contrary to the size of an invisible annotation of the state charts is reaching a maximum size of 77 characters 9 2 4 Modelling Interaction Supported communication model In Rhapsody interaction between the components can be reached by using shared variables communicat ing via messages as well as firing events In contrast to most of the other tools the handling of messages is not managed by Rhapsody itself thus this task is delegated to the target s operating system This means that there are different communication semantics on each platform However the developer has the possi bility to define a custom layer between the generated code and the operating system and fine tune it with the OS definition tool to influ ence the used mechanisms This can be extended to the point where no target operating system in necessary To avoid this additional layer we did not use the technique of mes sages in our model Suitability of the communication model In the implementation of our model we mainly used the technique of shared variables to communicate between the different components Especially so called conditions boolean data types were used as flags to signalize changes and trig ger actions in other components As most communication between components in our models consists of start or stop sign
13. Benutzermanagement lt lt interface gt IMGMT signal MGMT_SET signal MGMT_1 signal MGMT_2 signal MGMT_3 signal MGMT_4 E ISitzposition bminternport tu rentriegeln startfunkschluessel startMGMT E IFurkschluessel externerPort LOW_SITZ Figure 11 5 Definition of Signals and Interfaces nals and interfaces of the port can be defined as incoming called re quired in Tau or outgoing named realized A new type of diagram in UML2 0 is the architecture diagram It con sists of parts which are instances of classes and that are linked with each other via their ports see Figure 11 6 Ports can be defined ei ther in class diagrams or in architecture diagrams The ports of a part can be made visible if they have been defined before The channel between two ports is specified by a name the signals and interfaces exchanged by the ports and their direction The last type of graphical notation to talk about is the state chart diagram see Figure 11 7 The different states of a class can be de fined as well as the transitions between them A variety of symbols is available for performing transitions For example a trigger for a transition can be defined by an incoming signal symbol directly after a state The transition can only be performed if a signal that trig gers the transition is received Sending a signal is described by an outgoing signal symbol bran
14. General Aspects In the following paragraphs the main aspects of Rhapsody in MicroC will be discussed Functionalities Thus Rhapsody in MicroC is a model based development environment it s main functionality is modelling systems Rhapsody offers graphical editors for drawing diagrams By drawing diagrams both the structure and the functionality of the system can be mod elled For example statecharts flowcharts and truth tables are avail able Furthermore the developer can import his own C code into the components But additionally there are a number of functionalities which sup port the engineer in the whole development process Rhapsody in MicroC holds tools to automatically generate a documentation of the whole model and to generate code for different target platforms Also it helps to test the system by using graphical input output panels where the user can feed values into the model and watch the out put in the panels The graphical back animation module offers the possibility to animate the diagrams during simulation This is the From the Rhapsody in MicroC manual 155 156 CHAPTER 9 RHAPSODY IN MICROC stInclude git lt lt ifcelude gt lt lt Include gt gt n E us gt uu mul ome x __ ecmelude lt tInclude zi Include 3 SITZVERSTELLEN PROFIL SPEICHERN BENUTZER Include TUERSCHLOSS Figure 9 1 Example use case diagram main way of high
15. ISitzposition signal sw Integer signal sv Integer signal sh Integer signal ss Integer signal shor Integer Figure 11 15 Class Diagram for Internal Signals 11 5 2 Architecture The structure of the model is described by architecture diagrams which de fine which parts instances of classes work together We created five archi tecture diagrams one for the internal communication of our core system one for the user interface and three for specifying communication channels between the environment and each of the parts of the core system The architecture diagram for the user interface shows which signals are sent from the user to each of the three core parts see figure 11 17 In the architecture diagram for the internal communication the part BM Benutzermangagement handles the remote controll of the key and the user management buttons It stores the users seat positions and generates and sends signals for the TS Tuerschliesser and the SE Sitzeinstellung 224 CHAPTER 11 TELELOGIC TAU Sensoren sensorport IF hrzeugsensoren BATT FZG V Motoren 0O meterpert ISitzmotoren Treiberschicht outport IBlinken B_LOW_SITZ IZustand IWin rechtesTSG F OFFEN ZV_SCHL_L rtsgport SCHL R DOOR STATE Zustand B LOW SITZ ZVMotor OQ
16. Linux and RTLinux but we haven t used this system In preparation VxWorks RT Target RTKernel OS X Support with ANSI C generation for the following targets the runtime system protos Virtual Machine as modular source code and Project Templates are available for a quick start e Infineon C166 family Trice supports the C166 family of 16 bit microcontrollers by efficient C code generation Furthermore special features of these controllers are supported e g the CAN controller of C167 CR We have used this plattform with the help of Protos to generate the plattform dependend C code In our view we are satisfied with the easy steps to change the target system 236 CHAPTER 12 TRICE TOOL BY PROTOS SOFTWARE GMBH e 8051 family From the graphical models of Trice it is also possi ble to generate efficient C code for 8 bit microcontrollers The minimal requirements for application of Trice generated C code on a microcontroller target is a periodical function call which triggers the Trice scheduler e g a 1kHz timer interrupt can be used Hence Trice models may be integrated in every existing project Code size Code generated in ANSI C for the Infineon C167 CR Microcon troller Source code approx 13 000 lines of code RAM aprox 10 kByte without optimizing ROM aprox 30 kByte without optimiz ing These numbers still include the simulation and extra modelled components Readability of code Code is highly readable and well
17. BSProtocol e Behavior The following state chart diagram shows the behavior of the BenutzerManagement capsule This diagram contains six states BMcontrol this state provides transitions to call a saved seat position when a signal form the can bus is received BMAGMI BMAGM2 BMAGM3 BMAGMHZ these states pro vides transitions to save the current seat position AbspeicherungBM this state will be used as a transition state when the driver press simultaneous the MGMGSET button and one of these following buttons BMGMT1 BMGMT2 BMGMT3 BMGMTA 198 CHAPTER 10 RATIONAL ROSE REALTIME mgmt 2mgmt 3 mgmt 4 M pos 1 M pos 2 Y 7 Mpos 3 it fir i M pos 4 BM Control ERE 7 T A timeo M save 2 h wert 2 wert 2 h wert 1 w wert 1 mamt set hoc wert 4 Wertc4 hor wert 3 mgmt set stop Abspeicherung BM SitzEinstellung Design The following class diagram shows the aggergation hierarchy of SitzEin stellung capsule This capsule contains the following capsules 1 Controller N SitzSteilerFlacher 3 SchalungEngerWeiter 4 SitzVorZurueck 5 flaecheVorneSinkeHeben 6 flaecheHintenSinkenHeben 10 5 MODEL OF THE CONTROLLER lt lt Capsule gt gt Controller counter int 2 g int 3 pbatt int 12 istwert_h int 5 istwert_hor int 5 istwert_s int 5 istwert_y int 5 istwert_w int 5 amp sollwert_hor int
18. Botschaft 0x28d CAN M SAVE 1 CAN M SAVE 2 CAN M SAVE 3 CAN M SAVE 4 Intern gibt es Verbindungen zur Sitzeinstellung Verhalten Generell Verwendung der Tasten des Benutzermanagements Bet tigt der Fahrer eine der Tasten MGMT 1 MGMT 2 MGMT 3 oder MGMT 4 so wird die Einstellung die unter dieser Speicherposition abgelegt ist abgerufen Dazu wird e die CAN Botschaft M POS 1 M POS 2 M POS 3 oder M POS 4 0x28d generiert je nach gedr ckter Taste und e die Sitzeinstellung angesto en wobei als Soll Werte die Werte genommen werden die unter der Speicherposition abgelegt sind die der gedr ckten Taste entsprechen Wurden unter der jeweiligen Speicherposition noch keine Einstellungen abgespeichert so entfallt das Ansteuern des Sitzes Abspeicherung mittels der Tasten des Benutzermanagements Bet tigt der Fahrer die Taste MGMT SET und gleichzeitig eine der Tasten MGMT 1 MGMT 2 MGMT 3 oder MGMT 4 so werden die aktuellen Einstellungen unter der zugeh rigen Speicherposition abgelegt Dazu wird e die CAN Botschaft M SAVE 1 M SAVE 2 M SAVE 3 oder M SAVE 4 0x28d generiert je nach gedr ckter Taste und e die Werte der Sitzeinstellung SPOS HOR SPOS H SPOS V SPOS S und SPOS W unter der entsprechenden Speicherposition abgelegt Abruf einer Einstellung ber CAN Empf ngt ein TSG die Botschaft M POS 1 M POS 2 M POS 3 oder M POS 4 so wird die Einstellungen f r den Sitz entsprechend der gespeich
19. Elements used Interface Device Multidrop Bus Subsystem Actor Link Event Message unused Disk Board 56 CHAPTER 5 TOOL ARTISAN REALTIME STUDIO For describing the static system structure the Class Diagram is designated Elements used Class Attribute Operation Generalization Aggregation Association Uni directional association Dependency unused Package Association class link Ternary Association Exter nal Class The Use Case Diagrams details the ways in which a designed system can be used Elements used Actor Use Case Interaction Extend Flow Include Flow unused Generalization Key Use Cases can be explored by modeling a Sequence Diagram which shows the system interaction Elements used Sequence Selection Outcome Iteration Parallel Also Par allel Actor Interface Device Subsystem Package Class Timing Constraints Operation Event Include Probe Ex tend Probe unused External Class The behaviour and the aspects of a system concerned with time and the sequencing of operations will be defined in the State Diagrams Elements used Initial State Final State Atomic State Transition Event Ac tion Block unused History State Junction State Sync State Concurrent Com partment Synchronization Sequential State Concurrent State Activity An Activity Model Diagram can be used to
20. Nicht entprellter Mikroschalter gegen Masse analog Abbildung 5 Schlo nu schalter Anschl sse 19 KEY_STATE Charakteristik ber ein Widerstandsnetzwerk werden die verschiedenen Tasterstellungen codiert siehe Abbildung 6 Abschlie en Aufschlie en Vec TSG Abbildung 6 Anschlu charakteristik Schlo nu Schlie motor Zentralverriegelung Anschl sse 20 ZENTR_MOTI 21 ZENTR_MOT2 Charakteristik 12 V fiir 2 sec 0 3 sec verriegeln die T r 12 V fiir 2 sec 0 3 sec entriegeln die Tir Die Leistungsaufnahme des Schlie motors betr gt 18 W 3 2 2 Stecker S2 Externe Elemente Die Kontaktierung ist durchg ngig mit versilberten 0 63mm Kontakten im Macro Tripplelock System auszuf hren Abbildung 7 zeigt das Steckerbild 1 29 44 Bo oolno 4 5 agaonanaognoononn l6 nadgaanaumnmduuua 28 PJSO0000 DO 000000035 Abbildung 7 Steckerbild S2 9 Tabelle 2 beschreibt die Belegung des Steckers im Uberblick Anschlu Bezeichnung In Out Beschreibung 1 MASSE Signalmasse 4 SITZ_HOR In Sitztaster Sitz vor zur ck 5 SITZ V In Sitztaster Sitzfl che vorne heben senken 6 SITZ H In Sitztaster Sitzfl che hinten heben senken 7 SITZ S In Sitztaster Schalung enger weiter 8 SITZ W In Sitztaster Lehnenwinkel steiler flacher 9 SPOS HOR In Sitzposition Ist Wert Si
21. Object Col 51 52 CHAPTER 5 TOOL ARTISAN REALTIME STUDIO laboration Diagram Object Sequence Diagram State Diagram Use Case Diagram and some enhanced diagram types these are Concurrency Dia gram Constraints Diagram System Architecture Diagram Table Relation ships Diagram General Graphics Diagram Text Diagram Out of the de veloped model Code Generators for Java C C and Ada undertake the tasks of generating code skeletons Furthermore ARTISAN RT Studio offers two simulation techniques for validating the models With Object Animator the interactions within the modeled object sequence diagrams can be visualized and the State Ma chine Generator generates code to simulate the behaviour of the system An extension called Altia Faceplate in combination with the State Ma chine Generator can even be used to create simple demo applications The Document Generator is responsible for the documentation pro cess The result is a Microsoft Word document which can be edited further on It contains the details of the different diagrams Configuration management is based on a central database where all models are interconnected with one another So it is possible to work in a team without running into the failure of inconsistency Each code genera tor includes the funtionality to synchronize code with a model to keep the source code and model in step Test management and test case generation is described at length but th
22. This technique is the so called bypass technology Adequacy Oscilloscopes see Fig 6 10 on page 87 numeric displays and calibration editors are very helpful features the tool offers Numeric and logic parameters can be calibrated easily via calibration editors during Offline Experiments Parameters can also be stimulated through mathematical functions such as sinus cosinus ramp etc ET aeg File Edit View Extras Figure 6 10 sinus signal red ramp signal green Debugging Features The tool offers no real debugging feature but Of fline Experiments can be executed step by step and therefore you can follow the processing of the experiment s execution Another very useful feature is the run time display of parameters during Offline Experiments 88 CHAPTER 6 ASCET SD Testing Resulting measure data can be stored in a range of different file formats and utilized in further test cases or for coverage analysis There is also the possibility to collaborate with Matlab Therefore a proper measure data file is generated the Matlab m file and can be displayed via Matlab because display and analysis possibilities of this tool are bigger Certification ASCET SD is TUV certified for safety relevant applications Requirements tracing ASCET SD supports no tracing of requirements in the development process There are also no interfaces to requirements engineering tools 6 3 4 Applied Target Platform Target code genera
23. V Soll1_H Soll S Subject T Information Best formation AutoChegk completed with D messages lb ISTE IE Messe ASS Autocheck Id of O Emm Modelling Elements Status Diagrams Figure 11 1 User Interface Messages diagrams architecture diagrams state chart diagrams and state ma chines are available There are also Text Diagrams In order to group classes you can define packages The packages build up a hierarchical organization of the system In use case diagrams see Figure 11 2 you specify different kinds of Figure 11 2 Use Case Diagram actors for the users of the future system symbolized by stickmen You can also use generalization and inheritance leading to a certain hierar chy of roles The use cases themselves are represented by ovals Their description is hidden in its property window where you can provide 204 CHAPTER 11 TELELOGIC TAU textual information about pre and postconditions the course of ac tion and exceptions The use cases can be linked with each other us ing the include or extend dependency they can be grouped by a system boundary called subject and linked with actors by a perfor mance line because the actor performs a certain action env 1 SE 1 TS 1 mot 1 SIL Z SOB ie X sitztimer 0 1000 sizzuueck_ X sitztimer SMQI HORA BEN imer 0 4000
24. Wird innerhalb von 3 sec nicht das Verriegeln der T r erkannt so wird der Verriegelungsvorgang abgebrochen es wird die CAN Botschaft ERROR KEY generiert Nach erfolgter Verriegelung oder wenn das Fahrzeug ohnehin schon verriegelt war werden vom linken TSG soweit nicht das rechte TSG innerhalb von 1 sec die Fehler Botschaft ERROR KEY sendet die Signale BLINK 1111 und DURATION 50 zweimal hintereinander im Abstand von dt 1000 ms gesendet Trat ein Fehler beim Verriegeln auf so wird nicht geblinkt Automatisches Schlie en der Fenster Beim Verriegeln werden die Signale WIN VL CL WIN VR CL mit dem Wert 10 vollst ndiges Schlie en gesendet um die Fenster automatisch zu schlie en Unplausible Sensorwerte Wird festgestellt da eine T r offen ist F OFFEN 1 wobei gleichzeitig die T r verriegelt ist F_RIEGEL 1 so gilt e die T ren werden entriegelt s o e und es wird das Signal zum T r ffnen gesendet ZV_SCHL_R 01 Initialisierung Bei der Initialisierung des TSG wird gepr ft ob der Zustand der T ren konsistent ist Wenn nein dann werden alle T ren ge ffnet s o 22 6 Zus tzliche Richtlinien zur Modellierung 6 1 Inkrementelle Entwicklung In der inkrementellen Entwicklung wird schrittweise die Funktionalit t des zu entwickelnden Systems erweitert Um die M glichkeiten der inkrementellen Entwicklung und der Wiederverwendung mit den CASE Werkzeugen zu erproben wird die Funktionalit t
25. channels with name or type conflicts in red The same could be done with transitions and components facing parameter or name conflicts 110 CHAPTER 7 AUTOFOCUS This way it is easy to see problems right away e syntactic consistency The type correctness can easily be tested by the consistency checks of AUTOFOCUS Problems here may be that AUTOFOCUS can t find parts of the system This happens when DTDs are split up in more files and a subsystem consistency check is made Some times the consistency check is even too exact and points out pos sible problems that are not relevant e semantic consistency The semantic correctness is best tested by simulating the sys tem There the way of the data trough the system can be viewed graphically and errors can be easily detected Unfortunately there is no possibility to auto compare the simulation result with EETs created during the analysis process Still it is possible to create EETs of the simulation and to check the correctness man ually Component library Various predefined libraries are available We didn t use this feature because they didn t contain suitable components for our project It is possible to build user defined libraries They can be imported and used like the predefined ones Within this project we didn t build such a user defined library because the reuse functional ity we needed was also provided by copy paste and STD assignment It may be interesting to buil
26. cially toward control algorithms the MATLAB specification has a slightly higher complexity for this event based case study For Telelogic Tau the deviation can be attributed to the more structured representation of state diagrams similar to SDL In case of Trice overlaps in the representation where counted multiply otherwise basically a result close to the statistics of Rose RT would have been measured 3 2 4 Operational Model Obviously the choice of the operational model used to interpret the dia grams influences the complexity of the description For instance an op erational model supporting buffered communication can simplify the de scription of a message handling strategy Furthermore it also influences the expressibility of the modeling language For instance a formalism sup porting the explicit description of parallel events allows to detect simulta neously occurring events which is not expressible in a language without this feature Therefore in this section we give a short description of the operational model underlying the tools When describing the behavior of a reactive system the description of interactions between its components plays a central role The interaction is influenced by two different forms of synchronization Message Synchronization This form describes the coupling of sender and receiver of a communication Message synchronous communication corresponds to a handshake communication blocking the sender of
27. has a sub state machine where the action of opening or closing are performed This actor has no additional code and no SAP An example where we use SAPs is when there is a timer needed in the logic of the im plementation In order to get a better understanding of the modelling technique of the Trice Tool following we describe one of the main functionalities in detail Tuerriegelung TV Tuer Riegelung Links The TV is a main functionality of our model and its responsibility is to con trol locking and unlocking of both doors The TV takes over the responsi 240 CHAPTER 12 TRICE TOOL BY PROTOS SOFTWARE GMBH o zetDionrs tt x m Cr datas auge bobe rr ktgrfft ge boteng hey abschliessen eck es 13 hes aback lessen 12 errorregel T 11 ertrkgetrkgel Kite rte get wrregeltregel kterrord bey anschikssenzchkes tue rege Ito Ktrckb r awicklbrzeig Figure 12 3 Behaviour of actor class a_Tuere 12 5 MODEL OF THE CONTROLLER 241 bility for both motors in order to have a synchronous opening of the doors It cannot communicate directly with other doors as this communication is made over the CAN Bus in this case study If the right door is opened then the right TSG sends a message over the CAN Bus so that the left TV can start the un locking of the doors The functionality of the right TSG is not explicitly shown as this was out of the scope of this task The structure of Tuerriegelung can be seen in Figure 12 4 It contain
28. ot TE SPA P fitikcwecoreci Pos ACHSE v CNTe v POS h ACHSE x e CNT2H P051 enne y E cD 3fs Tesema y pad not TSEMA_HI f Figure 9 12 Example structure diagram AGEMENT automatic adjustment or directly through the environment activity SITZVERSTELLTASTER which encapsulates the input signals from the user devices A screenshot of the activity is shown in Figure 9 13 The activity SITZSTEUERUNG consists of one control activity called SITZEINSTELLUNG_MANUELL where the functionality is implemented as a state chart SITZEINSTELLUNG_MANUELL see Fig 9 14 has one main state which includes five parallel subcharts one for each axis in the seat Each of the subcharts is implemented in a similar state automata with three states idle opening and closing The requirement of only two mov ing axes at the same time is reached through semaphores To guarantee consistent and efficient reactions to exceptions like an open door a too high velocity of the vehicle or a too low battery voltage inter ruption of the seat movement is implemented in the main state chart by using hierarchy Component TUERSTEUERUNG This chart handles the door locking func tions It is connected to BENUTZERMANAGEMENT in order to receive input signals from the wireless keys and gets input from various sensors indicat ing the current door state open closed the state of the door lock etc Output signals are generated and passed to the environment activity ZE
29. that makes an average of approximately 6 5 The maximum number of edges counted in one view is 44 Visible annotations The size of visible annotations amounts approximately 12 300 characters The most extensive comment contains about 250 characters Invisible annotations We have not used any invisible annotations be cause these annotations are intended only for the automatic model documentation and do not facilitate the readability It is not neces sary to fill this information for generating the document but then obviously the description is missing 6 2 4 Modelling Interaction In this section we describe the system model used by the description tech niques Supported communication model e Synchronization concerning event scheduling In a module there can be defined divers processes and every component has to be assigned to one of them with a sequence call number The sequence call determines the component s rank in the block and therefore the order in which the process is ex ecuted These processes can be stimulated namely either by 6 2 MODELLING THE SYSTEM 83 ASCET SD itself only simulation or by the target platform s real time OS like ERCOS FF They can be stimulated cyclic e g every 50ms or by an event like a software or hardware interrupt by the last two only if they were stimulated by the OS Hence all the synchronization in the model is realised by processes I O synchronous Input and output can occ
30. zvport IZVMot Figure 11 16 Class Diagram for Environment see Figure 11 18 The Tuerschliesser class manages the centralized door locking If any of the axes of the seat has to be changed the Sitzeinstel lung cares for the right movements It acts in three different situations if the remote controll button of the key is used if one of the user management buttons is pressed and if the user adjusts the axes manually If the remote controll button is pressed all axes are moved simultane ously because the driver is outside his car In the second case however a certain order of moving the axes must be kept firstly the movements that give the driver more space then the others Moreover only two axes are moved at the same time Also when the driver adjusts the seat position by pressing the equivalent button he can only move two axes maximum simultaneously 11 5 MODEL OF THE CONTROLLER 225 S ISitztaster es externport SE Sitzeinstellung IMGMT is iil sel P um externerPort BM Benutzermanagement u TTustsshs ren Lm Tuerport S Tuerschliesser Figure 11 17 Architecture Diagram for the user interface 5 2 BM Benutzermanagement M POS 1 brninternpore osition ttTB benutZ anagement funks hluessel startfunksc sselJstartMGMT Tuerstatus B D tuerchec sitzinternport tuerentnegeln SE Sitzeinstellung
31. 0x28c 1 4 M SAVE 1 wie 0x26c 1 5 M SAVE 2 wie 0x28c 1 6 M SAVE 3 wie 0x28c 1 7 M SAVE 4 wie 0x28c 1 e 0x6fe spontan 0 0 B_LOW_SITZ Batterie f r Sitzbewegung 1 zu gering 1 B LOW KEY Batterie f r Schlie ung zu 1 gering 2 ERROR KEY Fehler beim 1 Schlie vorgang S Ox6ff spontan 0 0 B LOW SITZ Batterie f r Sitzbewegung 1 zu gering 1 B LOW KEY Batterie f r Schlie ung zu 1 gering 2 ERROR KEY Fehler beim 1 Schlie vorgang x 0x710 zyklisch 200 0 0 DOOR STATE Zustand der T ren x1 x2 2 xl vorne Links 1 T r offen x2 vorne Rechts 1 T r offen X 0x780 zyklisch 200 0 0 F T OFFEN _ Zustand der T ren 1 Fahrerseite x1 x1 Fahrert r 1 T r offen Tabelle 5 Verzeichnis aller TSG relevanter Kommunikationssignale Erl uterung e Die Zuordnung einer Botschaft auf zwei TSGs Sende Empfangsstatus x dient der Einsparung von CAN Identifiern Andernfalls h tten immer zwei Botschaften vorgehalten werden m ssen wie z B bei 0x004 und 0x005 was mehr Realisierungs und Kommunikationsaufwand zur Folge h tte e Botschaft 0x100 o Die Signale sind kumulativ d h neben der aktuellen Z ndungsstufe sind auch immer alle niedrigeren Z ndungsstufen mit aktiviert e Botschaft 0x22d o Das eigentliche Blinken wird von entsprechenden Aktuatoren Blinker Kombiinstrument eigenverantwortlich durchgef hrt Sobald eine Botschaft mit BLINK 0000 empfangen wird erfolg
32. 10 CHAPTER 1 INTRODUCTION are necessary to extend this state of the art into a model based develop ment process 1 1 Overview The report consists of three parts Preface In the first part we describe the questionnaire used to asses the tools Chapter 2 give a short summary of the results Chapter 3 and sketch what is to be expected from model based CASE support in the future Chapter 4 Tools In the second part for each tool we include the results as described by the students e ARTISAN RealTime Studio Chapter 5 e ASCET SD Chapter 6 e AutoFOCUS Chapter 7 e MATLAB StateFlow Chapter 8 e Rhapsody in MicroC Chapter 9 e Rose RealTime Chapter 10 e Telelogic Tau G2 Chapter 11 e Trice Tool by Chapter 12 Requirement Specification In the last part we include the requirement specification as used in the case study 1 2 What This Report Does Not Aim At The case study focuses on the use of CASE tools for the specification of em bedded software Therefore several aspects essential to the development of embedded systems are not sufficiently addressed to supply a complete and sufficiently detailed picture of the tools These aspects include e Ease of deployment to specific operating systems e Ease of deployment to hardware platforms e Memory and processor efficiency of the generated code e Integration in a tool chain e Availability of rapid prototyping environment 1 3 WHAT THIS REPORT DOES AIM AT 11 Ac
33. 107 value attribute is set the incomming data is kept as long until a new signal is put on the chanel It is not consumed by reading it so the signal can be read as many times as desired If the imme diate attribute is set the signal is passed in no time Normaly it takes a cyle to pass the signal on but this way it doesn t One has to be careful to keep the structure loopless Otherwise situations can occur that don t have a defined outcome e g deadlocks e In AUTOFOCUS no shared or global variables exist The local varaibales can only be seen within the components Because of that the components can t communicate using global data fields They have to exchange their data using messages which is some times not very convenient e Blocking communication is not supported All communication is done synchronous But it is possible to buffer messages by us ing the keep value attribute of ports as described in the section above Communication model suitable The communication model has been suit able but a more sophisticated buffering strategy would have been nice eg FIFO Timing constraints AUTOFOCUS supports the immediate port notation This way a message can be passed within the same clock cycle if possible This helps to solve timing problems During the case study we relied much on the timer signal that could be read from the CAN bus This way it was easy to model timeouts of signals The system time was then just
34. Die wei unterlegten Elemente bezeichnen diejenigen Fahrzeug Komponenten mit denen das TSG direkt interagiert ber Sensoren und Aktuatoren die direkt mit dem TSG verbunden werden Neben diesen direkten Ein und Ausgabeeinheiten gibt es eine Reihe externer Einheiten mit denen das TSG ber den CAN Bus kommuniziert z B Kombiger t oder Telematiksystem Im Folgenden werden die in Abbildung angedeuteten drei Funktionalit ten des TSG in informeller Weise aus Benutzersicht n her beschrieben Sitz Sitzverstell Sitzmotoren position taster Benutzermgmt __ taster TSG Sitz AAs einstellung Griffleisten gt sensor Schlo nu gt schalter Benutzer pu management T r Offen Sensor Zentralver lt T rschlo riegelungsmotor urschlo T rverriege gt lungssensor CAN Bus Innenraum Abbildung 1 Schematische Darstellung des TSG mit seinen peripheren Komponenten 2 4 Sitzeinstellung Vor dem Antritt einer Fahrt kann der Benutzer den Sitz gem seinen Anforderungen einstellen Er hat dabei die M glichkeit e den Winkel in dem die Sitzlehne steht e die Entfernung des Sitzes vom Lenkrad e die H he des hinteren Sitzbereichs e die H he des vorderen Sitzbereichs und e die Schalung des Sitzes zu verstellen Die Einstellung der Sitzpositionen ist nur bei ge ffneter T r m glich Die n heren Einzelheiten sind in Abschnitt 5 2 beschrie
35. RT Buffered event driven Rose RT uses a buffered communication model additionally supporting an explicit wait for a return value Components get activated whenever messages are available if a com ponent is not ready to accept messages from sending components those messages are stored in a message queue in the order of arrival Tau Buffered event driven Telelogic Tau uses a buffered communica tion model Components get activated whenever messages are avail able if a component is not ready to accept messages from sending components those messages are stored in a message queue in the or der of arrival Timers are used to generate time out messages Trice Buffered time driven Trice uses a buffered communication model Similar to AutoFOCUS during a cycle of the system each component executes a step if a transition is enabled Additionally timers can be used to generate timeout messages If a component is not ready to ac cept messages from sending components those messages are stored in a message queue in the order of arrival Generally all operational models have been found sufficient by the users of the tools However extensions of the models with simple properties can sometimes reduce the ease of handling Examples are Signal buffering In signal based communication explicit buffering of mes sages can reduce the complexity of the model in situations with weak synchronization of the models Channel based communication F
36. RealTime online docu mentation provides a wealth of information and includes a compre hensive online help system The content is fully searchable and con tains rich multimedia Usability The usability of the tool is very good The main elements of the Rational Rose RealTime user interface are very easy to use The toolbar Menus Browsers Diagram Editors Specification Dialogs 10 2 Modeling the System 10 2 1 Available Description Techniques Supported notations In addition to supporting the core UML constructs Rose RealTime uses the extensibility features of the UML to define some new constructs that are specialized for real time system devel opment There are eight diagrams supported in the Rose RealTime tool not all of them are required to create an executable model Al though not all diagrams are required they exist for a purpose the combination of these diagrams provides an excellent description of the total composition and behavior of the model The supported diagrams are e use case diagrams Example SitzEinstellen Use Case diagram 10 2 MODELING THE SYSTEM 181 gt WinkelEinstellen lt lt inchoe gt lt lt hchde gt gt qu Sitz vom Lerkr ad entfernen c H he des hinteren Sitzbereiches einstellen e H he des vorderen Sitzbereiches einstellen A Fahrer SitzEinstellen from MainDiagram lt lt chchde gt gt from MainDiagram Schalung des Sitzes einstellen e
37. SPOS H S2 SPOS S S2 SPOS_W e Batteriespannung CAN BATT e Fahrzeuggeschwindigkeit CAN FZG V Intern gibt es eine Verbindung zum Benutzermanagement Ausg nge e Sitzmotoren S2 SMOT HORI S2 SMOT HOR2 S2 SMOT_ V1 S2 SMOT_ V2 S2 SMOT HI S2 SMOT_H2 S2 SMOT S1 S2 SMOT S2 S2 SMOT WI S2 SMOT W2 e Wammeldung CAN B LOW SITZ Verhalten Generell Ein Verstellen der Sitzposition ber die Sitztaster ist nur m glich wenn die dem TSG zugeordnete Vordert r ge ffnet ist F OFFEN 1 Das Verstellen der Sitzposition ber das Benutzermanagement ist auch bei geschlossener T r m glich Die Sitzposition wird entweder entsprechend der vom Benutzermanagement gesendeten Positionsangaben oder den Sitztasten eingestellt Dabei gilt das Prinzip da immer die zuletzt benutzte Taste Benutzermanagement oder Sitztaste die Bewegung des Sitzes bestimmt Bewegung des Sitzes Zur Bewegung des Sitzes werden die in Tabelle 3 angegebenen Spannungen auf die Sitzmotoren gelegt Die Bewegung wird solange durchgef hrt wie e Ist Wert und Soll Wert nicht bereinstimmen bei Anfahren einer Sitzposition ber das Benutzermanagement bzw die Sitztasten gedr ckt werden bei Verstellen der Sitzposition ber die Sitztasten e und der Wert der Sitzposition keine Unterbrechung erkennt Bewegung ber Sitztasten Bei der Verwendung der Sitztasten k nnen maximal zwei Bewegungsrichtungen gleichzeitig verwendet werden Wird w hrend der Sitzve
38. The S Functions are compiled and can afterwards be masked i e a dialogue can be created with which the user later can customize the block s parameter In Stateflow there exist only few predefined components empty states junctions and history junctions and transitions Development history MATLAB itself and also Simulink and Stateflow does not provide functionality for keeping a development history or recover old development states but it offers interfaces to three pop ular source control systems which are Rational ClearCase Merant PVCS Version Manager and the Revision Control System It also al lows the user to set up a custom interface to other source control sys tems Information about version number author date of last change etc can be displayed in Simulink with the help of the Model Info block which can also contain further customized text 8 3 3 Applied Quality Management The specification contained several faults and uncertainties where we had to find our own solution These faults are described in the appendix of this document As the tool does not provide analysis functionality we had to discover the faults ourselves by working through the specification Host Simulation Support Simulink provides the ability to simulate the the model on the PC or workstation used for development There fore it converts the model into code and executes this generated code While this takes place Stateflow can animate the activ
39. We missed the ability to assign a value to an event which led to double input output ports for the interaction with the CAN bus our realization required one data and one event output per 128 CHAPTER 8 MATLAB STATEFLOW CAN communication Also something like UML sequence diagrams for modeling interaction would have been useful 8 2 3 Complexity of Description Views Each level of hierarchy in our model is a view Nodes The nodes of our model are states and junctions Edges Edges are state transitions in Stateflow Visible annotations The graphical functions and the transition annota tions represent the visible annotations in our model We could not count them based on the number of characters used as the functions also consist of graphical elements like junctions and transitions Invisible annotations We don t have any invisible annotations in our model The figures for the single items are shown in Table 1 on page 128 In our whole model there are 90 views representing the different levels of hierar chy average per maximum model total view per view nodes 3 2 19 292 edges 3 8 19 338 visible 385 annotations invisible 0 annotation Table 8 1 Number of views nodes 8 2 4 Modeling Interaction Supported communication model Systems modeled with Simulink can be simulated in continuous or in discrete time or in a hybrid of the two The simulation is realized by a numerical
40. a certain part of the diagram This helps to keep the model clear but still be able to get the needed in formation Unused notations We didn t use the Extended Event Traces in the analy sis phase of the process but only the auto generated EETs from the simulation environment Missing notations As the provided notations were suitable for the model we didn t miss any notation in special 7 2 3 Complexity of Description Views In the whole model are altogether 31 Views including non atomic SSDs amp the STDs of the atomic SSDs 106 CHAPTER 7 AUTOFOCUS Nodes The number of nodes is 122 including 43 components and 79 states Each view contains an average of about 4 nodes The view with the maximum count of nodes has 16 nodes Edges In the whole model there are 150 channels and 169 transitions which is altogether 319 edges This is an average of about 7 edges per view The maximum number of transitions in one view is about 40 channels in the SeatControl component Visible annotations In the SSDs there is nearly everything visible except the local variables and initial default values In our model there is nearly 95 visible In the STDs the transition semantic is visible if it is not hidden behind a label We did use the option to label the transitions in most cases to keep the view more accessible so only about 30 of the annoations are visible Invisible annotations The DTDs are complete invisible anno
41. a summary of the perceived strengths and weaknesses of the tools Obviously these perceived strengths and weaknesses do not always cor respond with the strengths and weaknesses experienced by expert engi neers Therefore features like support for platform tailored code generation e g Rhapsody in MicroC Trice in the loop tests or test case generation e g ASCET SD Telelogic Tau connection to project support tools e g Rose RT ARTiSAN transformations like discretization e g MATLAB Stateflow or verification e g AutoFOCUS were perceived as important issues Nevertheless these perceived strengths and weaknesses have a de cisive influence on the long term adoption of a tool As a conclusion all of the groups managed to design fully functional models of the case study in their respective tools The evaluated tools have shown a good balance of user support and usability support for quality control and target code generation As the only research tool in the com parison AutoFOCUS naturally showed some weaknesses regarding user friendliness documentation and stability while otherwise holding up well against the commercial tools MATLAB Stateflow ASCET SD Rhapsody and Trice being somewhat more targeted at small embedded targets have strong support for target code generation The tools from the classical SW engineering or telecommunications domain ARTiSAN Rose RealTime and Telelogic Tau excelled in terms of usability
42. actually the system is and so you are able to find failures in the model Testing Rhapsody allows you to create test vectors called test drivers or you can test the function by manual user inputs The test vectors only record manual user inputs The tool is able to write different test vectors in a own file while using a panel for simulating the model But these vectors include only the used variables in the panel and the user gets no written output about his testing process In conclusion the tool can t write a protocol of a test Certification The Code generator is not certified Requirements tracing Requirements tracing is implemented through the interface to the DOORS requirements engineering tool You can also manage the requirements by linking any kind of model elements to a word document or giving them a long description 9 3 4 Applied Target Platform Target code generation and supported target The possibility of free tar get choice is a strong feature of the tool Furthermore Rhapsody en ables the engineer to use every imaginable compiler On account of this the integration of a target compiler by using configuration scripts is supported by RiMC Example target adaptions exist for the Mo torola HC08 HC12 and Fujitsu MC16lx controller including compil ers from Metrowerks Cosmic and Softune Code size The generated code of the described project mount up to a size of 318 kB for Windows because of the graphical panels a
43. adjustment is possible The can bus state is very similar to the manual seat adjustment It too consists of five paralles substates one for each axes of seat adjustment In the following the state sitz vorne c will be described as an example the other states work in the same way In idle v c the model compares by a call to the function poscheck _sitz_vorne val the actual position of the seat with the one that is saved in the given memory If both positions correspond only the semaphore which counts the number of ready motors has to be increased by one and there is a transition to the state ende v c Otherwise the function auto zu schnell checks whether the car 8 5 MODEL OF THE CONTROLLER 145 can_check Z Imem_SET speicherplatz can_send _b_low_sitz 1 batt_low_sitz mem SET speicherplatz tasten_check_1 batt_low_sitz L Figure 8 14 State can_check has a speed of more than five km h If it hasn t the control flow goes over to state v1 where the direction in which the seat shall be moved is evaluated According to this information the corresponding motors are switched on and a transition to the following state v2_c takes place Here it is again tested if the saved position is already reached As soon as this is fulfilled or as the car gets too fast the motors of the seat adjustment are switched off the semaphore is increased by one and the state ende_v_c is activated State
44. advanced versioning features 5 3 3 Applied quality management Failures we ve found have already been corrected by the management team Host simulation support Simulation support is offered only for sequence diagrams and state charts Target simulation support Target simulation is not supported by ARTISAN RT Studio 5 3 DEVELOPMENT PROCESS 63 Adequacy The simulation feature is mostly for creating demos The sequence diagram simulation shows method calls and signals between objects in a relatively simple manner The tool called Altia Faceplate supports creating simple demo applications It consists of a graphical windowing toolkit combined with the possibility to send triggers to automatons which were generated out of the state chart diagrams These are nice features in order to showcase to the customer but it s not very valuable in the development process Debugging features There are no code debugging features available because there s no target code generator offered by ARTISAN RT Studio During the simulation of an automaton the current state is visualized Besides it is possible to set breakpoints in the simulation of the sequence diagrams Testing Except for the simulation which is sometimes useful for recognizing mod eling failures no test features are available within ARTISAN RT Studio Certification Full code generation except for class skeletons is not supported and has to be done with third par
45. algorithm called solver which can be chosen from several possible ones The solver can be adjusted to your needs by setting parameters like the step width between two calculations you can either choose a variable step width i e the solver computes the step width dynamically according to the value of the signal in your Simulink model or fixed step the step width 8 2 MODELING THE SYSTEM 129 stays the same during the complete simulation A Stateflow chart can be activated during the simulation of the sur rounding Simulink model in three different ways e triggered inherited the chart is activated either if an event is passed into the chart from the Simulink model or if one of the input data changes its value An event can be a function call or an edge of a signal rising falling or either of these e sampled the chart is woken up at fixed time steps e continuous the chart is fully integrated into the surrounding model and calculated with it Furthermore Stateflow provides techniques to include custom code and to share variables between the included code and the Stateflow model Inside a chart shared variables can be used for communication tasks In Simulink data flows explicitly between connected blocks and no shared variables are possible Communication model suitable The available communication model was fully suitable for our realization of the case study Timing constraints As there is an explicit time model in Sim
46. and connec tions between these blocks This specific notation stems from control theory and allows to realize control circuits Indoor Temp Tin Themmodynamic Model forthe House Outdoor Temp Tout Figure 8 1 Example for a block diagram e The Stateflow help mentions another form of diagrams flow diagrams These are special arranged state transition diagrams which realize decision making logic e g if then else statements Additionally Stateflow supports the Action Language as a non graphical notation which is a kind of programming language It is used to de scribe conditions for transitions or actions taking place within an ac tive state The general syntax for transition annotations is event condition condition action action Within an active state actions can be specified by the keywords entry during or exit Modeling aspects The provided notations can be used for modeling struc ture behavior and interaction Stateflow s flow diagrams can be used to create decision making logic such as if then else constructs or for 126 CHAPTER 8 MATLAB STATEFLOW AJ entry entA B entry entB during durA exit exitA during durB PX P exit exitB bw C three entry entC gt during durci exit exitC Di entry entD during durD exit exitD Figure 8 2 Example for a state transition diagram flow diagram loops without the use of additional states and thus ca
47. and user support A com mon weakness of all of the above tools seems to be the almost nonexistent support for automated or semi automated development steps like restruc turing and refactoring 3 4 CONCLUSION 41 Tool Strengths Weaknesses ARTISAN Good overall usability No explicit target code Tight consistency check generation ASCET SD Good support for mod Usability could be ular descriptions improved Wide variety of nota Loose consistency tions check Strong target code gen No integration with eration version management AutoFOCUS Good support for mod Weak usability ular descriptions Editor runs instable Good simula Consistency checks tion validation sup need improvement port Insufficient name Good readability of space concept generated code MATLAB StateFlow Good usability No sequence diagrams Rhapsody in MicroC Good modeling nota Built in database tion causes versioning Limited support for problems reverse engineering code Rose RealTime Good modeling nota Limited copy paste tion support Useful simulation and debugging environ ment Good interoperability with 3rd party tools Telelogic Tau Good usability SDL style notation may Fully constructive be be unfamiliar to UML havioral model developers Trice Good usability Documentation incom Strong target code gen eration plete Table 3 1 Strengths and Weaknesses of the CASE tools 42 C
48. because it does not offer techniques for require ments analysis or the modeling of use cases The missing use cases and sequence diagrams would also have been a helpful basis for creating test cases 8 3 DEVELOPMENT PROCESS 131 8 3 2 Applied Process Support Simple development operations Stateflow and Simulink both provide sim ple development operations like cut and paste for all kinds of com ponents or search and replace for all kinds of text including state names variables and transition annotations Additionally the tools support click and drag operations e g creating copies of existing elements or inserting prebuilt blocks from Simulink s library Complex development operations Simulink Stateflow themselves do not offer complex development operations like hardware partitioning but you can achieve this with add ons that are available through Math Works or other third party companies Reverse engineering Stateflow Simulink offers reverse engineering only for the re import of generated code which can also be modified or extended by the user if the user doesn t touch the specific syntax of the generated code In Simulink there also exists a special block called MEX S Function Wrapper that can be used to integrate legacy code functions or algorithms into a Simulink model User support MATLAB provides an import wizard which assists the user in reading data from binary or text files and writing them back In Sta
49. code in C or Assembler bytes of machine code bytes of used memory 2 4 CONCLUSION 21 Readability of code How good is the readability of the generated target code Does the generated code relate to the model structure 2 3 5 Incremental Development This section discusses how much the tool aids in the incremental develop ment process i e going from a two axes system to the five axes version Reuse How much of the original specification could be reused Restricted changes Could changes be restricted to a small part of the spec ification Modular design Did the tool approach help building a modular design or was a very modular structure found uninfluenced by the approach in the first stage Restructuring Did the tool support restructuring techniques e g refac toring 24 Conclusion Here a short summary of the strengths and weaknesses of the tool and its application is given especailly addressing the questions of what has been missing and what was very helpful in the development 2 5 Model of the Controller Finally a description of the model is given including e ashort description of the structure what are the main modules components etc e a short description of the functionality of each module component If possible original documents generated with the tool are included If reasonable also documentations of simulation protocols etc are included which help to document the correctness of the m
50. constraints Therefore you set the timer to the system clock plus a certain number of seconds for example timer now 3 When the timer ex pires a signal containing the name of the timer is sent We used the timers for the environment to send signal periodically and we used them for the centralized door locking After sending the signal to lock or unlock all doors we had to wait some seconds if the Tuersteuerg eraet of the other side sends an error warning So we set the timer and if the timer expires we suppose that there was no error at the other doors 214 CHAPTER 11 TELELOGIC TAU Realtime support The real time support is guaranteed by the timers where you can exactly specify the time when something should happen We didn t use this feature because it wasn t necessary 11 3 Development Process 11 3 1 Applied Process Our general principle was to start with a very limited functional prototype which we enhanced and restructured until we got the fully implemented system We began modeling with one class called TSG which handles the move ment of two axes of the seat We checked this part until there were no more errors visible in the autocheck which we will describe in the next section Using this as a core for our future system we added all the other function ality step by step This lead to a more and more complex model so that after some time we restructured the model into three classes In order to be able to te
51. design the dynamic aspects of a system Elements used Diagramtype not used unused Action Object Action State Sync Bar Decision Connector Initial State Final State Signal Send signal Receive Control Flow Object Flow The dynamic behaviour can be also described a Object Collaboration Diagram and so these type of diagram explains a usage scenario Elements used Diagramtype not used unused Actor Class External Class Link Operation Message Event Message 5 2 MODELING THE SYSTEM 57 A Constraints Diagram is an ARTiSAN RT Studio extension to the UML used for modeling constraints applicable to real time systems Elements used Consrtaints Type Constraint Link unused Concurrency Model Diagrams are an ARTISAN extension to the UML that describes the multitasking and concurrency processes that allow a system to execute within defined performance constraints asdfsadf Elements used Diagramtype not used Event Message Operation Message unused Class external Class Interface Device Task Channel Event Flag Mailbox Monitore Pool Semaphore Signal Link Table Relationships Diagrams are used for modeling persistent data storage Elements used Diagramtype not used tionship unused Table Column One to many relationship One to one rela A General Graphics Diagram is an additional dia
52. dn_TIME ime lt S _ in_TIME tme gt e2 ti Ican_send_error_key 1 In_T_RIEGEL 0 Y motor_zentralverriegelung AUS motor_zentralverriegelung AUS z_a_strom_2 evt TIME in_TIME time lt 4 in_ERROR_KEY 1 in RJ zo innen auf 1 in ERROR KEY 0 linnen_auf 0 Figure 8 6 State z_a_strom control passes over to z_a_blinken If the lock bar on the driver s side could not be opened within the specified three seconds the controller calls can_send_error_key to send a CAN message notifying the right controller of the failure switches off the motors and returns to the initial state z_a_start If both doors are unlocked the state z_a_blinken is activated in which a CAN message is generated and sent via the function can_send _blinker blink duration that causes the blinker to blink once for 100ms Afterwards the state offen becomes the active state and within offen the initial state is a_z_start Finally z_a_error is a state in which the model stays in case of the not properly specified case that the door should close according to the rule that both doors must be in the same state and open because one must be able to open the door always from inside the car at the same time State offen The super state offen is the counterpart to zu In its initial state a_z_start the model is waiting for events signals that indicate close the doors Possible events are e locking
53. einem 1 i zum Speichern der Sitzposition sp teren Zeitpunkt wieder abgefragt werden auf so werden diese Werte x ce r in die gew nschte Speicher i AR position geschrieben neuen Figure 6 6 Part of the block diagram for the user management literals constants arrays matrices etc and of arithmetic logical comparison and program flow control operators All these elements have input and output pins that can be connected and result in com bination to a complex circuit The textual equivalent of block diagrams is ESDL Embedded Soft ware Description Language This language has a similar syntax as Java and helps to model some functionality faster and easier than graphically That is for example the case when many junctions if else switch or loops for while are required or a high nested arithmetic expression like a b c d e d a has to be computed It is not a real programming language because Strings and other elements not needed to model embedded systems are missing The last offered description language is C The crucial difference be tween using ESDL or block diagrams and C is that the components in the C code are specified on the implementation level rather than on the model level This implies that the specified code has to be com prehensible for every target platform This technique is often used if C code for example for drivers is already available For interaction ASCET SD provides messages Mes
54. en T 30mm E 165 mm 30mm e i N i 137 mm i 180mm i N 30mm 30mm e bag N l Y e k VE ENA E EE ANE ENS pra d 30mm 22mm Abbildung 10 Position der Befestigungspunkte 12 4 CAN Kommunikation Nachfolgend sind alle Botschaften zusammengetragen die das TSG ber den CAN Bus sendet oder empf ngt Die Tabelle selbst ist wie folgt aufgebaut Spalte 1 TSG Sende Empfangsstatus f r das linke TSG o e Botschaft wird vom linken TSG empfangen o s Botschaft wird vom linken TSG gesendet o x Botschaft wird vom linken TSG entweder gesendet oder empfangen dies ist abh ngig davon ob es sich um eine Fahrer oder Beifahrer TSG handelt siehe jeweilige Fu note x Die Botschaft wird vom Fahrer TSG gesendet und vom Beifahrer TSG empfangen x Die Botschaft wird vom Beifahrer TSG gesendet und vom Fahrer TSG empfangen x Die Botschaft wird vom Beifahrer TSG gesendet Das Fahrer TSG ignoriert diese Botschaft x Die Botschaft wird nur auf eine Aufforderung hin generiert Spalte 2 TSGg Sende Empfangsstatus f r das rechte TSG o e Botschaft wird vom rechten TSG empfangen o s Botschaft wird vom rechten TSG gesendet o x Botschaft wird vom rechten TSG entweder gesendet oder empfangen dies ist abh ngig davon ob es sich um eine Fahrer oder Beifahrer TSG handelt siehe jeweilige Fu note bei TSG Spalte 3 ID Identifier der CAN Nachricht Hexadezimalwert Spal
55. example describe how you did start out in the development process defining system boundries describing initial use cases how you came up with a model of the system refining use cases by sequence diagrams defin ing data structures which further steps you applied simulation checks test etc For the development of the model we chose a very high level of ab straction to be hardware independent Given the structure and function ality of the Trice Tool we were able to graphically model the system from the beginning We started the development process by first defining the components involved in the description of the case study For each compo nent we defined its function responsibility and the role within the model Then we defined the interfaces for each component These interfaces rep resent the defined component s role internally and externally In the next step we modelled the structure of the system We grouped different com ponents according to their functionality and ordered them hierarchically where possible or reasonable Afterwards we modeled the behavior of each actor according to its func tionality and responsibility trying to keep a clear hierarchical structure At each step we were running the simulation to assure the correctness of each component refining the model when necessary All bugs and problems found during the simulation on basis of message sequence charts tracing etc were fixed as early as possible
56. generally focus on the support of the implementation Typical examples are the generation of schedules for computations e g ASCET SD ROSE RT Tau or optimizations for cer tain platforms Depending on how strong a tool supports the implemen tation phase some of these functionalities may not be available if the tool focuses on analysis and design e g ARTISAN Generally however most of the tools only have restricted complex development support for the anal ysis or design phase see also Subsection 3 3 2 For obvious reasons reverse engineering i e generating specifications out of code can only be partially supported by tools Generally it focuses on the structural parts of a system e g generation of class diagrams or is limited to code generated by the tool and hardly modified Consistency ensurance mechanisms When building a large specification broken up into several modules or di agrams frequently errors arise at the interfaces between those parts Ad ditionally specification errors also arise within each module or diagram when parts of these specifications are missing or to not fit together CASE tool can help to detect those inconsistencies to make the specification consis tent Model consistency can be supported at different levels Code Level On this level the tool does not directly support model con sistency Rather syntactic consistency is only defined on the level of the generated code generally the tool h
57. generated code Some tools ASCET Rational Rose RT Matlab Stateflow offer the possibility to set watchdogs for certain variables or events Be yond that only Matlab seems to provide a more elaborate code level debugger Testing Almost all tools allow parameter vectors to be played back dur ing a simulation and current simulation data to be saved for later use for example in regression testing Apart from that there is little support for test data management like batch processing of test suites and generation of test statistics Test coverage analysis is provided by Rational Rose RT interface to an external tool and Matlab However automatic generation of test cases out of the model does not seem to be offered by any of the tools Certification Most of the tools are not certified Trice has started a TUV certification Parts of ASCET have been TUV certified the exact ex tent of this certification is not clear Requirements tracing None of the tools directly integrates requirements tracing However several tools offer an interface to external require ments tracing facilities such as Doors The above remarks can be summarized by saying that the most impor tant quality assurance method is simulation The tools are generally very well developed in this area However debugging and testing are just understood as variations of simulation Genuine support for testing auto matic derivation of test cases test analysis i
58. motion function for pro cesses during the simulation With such a function you would not have to stop the Offline Experiment anymore to change the frequency of processes 6 5 Model of the Controller In the following section we give a description of the model we have built In doing so the three main components of our implementation will be pre sented and described in detail Additionally to the description of the struc ture of the model another considered point in this section will be the func tionality of these components 6 5 1 Structure Our model is composed of a project and three modules The project inte grates these modules see Fig 6 12 on page 92 In doing so it enables these modules to communicate among each other By the use of the project var ious tasks can be defined and assigned to each process used in the model This allows to simulate a working operating system and thereby to execute Offline Experiments Module 1 One of these three modules realises the CAN connection It contains a single class implemented in C code In fact the func tionality of the whole CAN connection is realised in this class The cause we used C code in this case is that the CAN connection is mod elled very rudimentarily To use a programming language instead of a block diagram or state machine was an advantage because the needed lines of code were less than the complexity of an equivalent block diagram 92 CHAPTER 6 ASCET SD
59. oe V areas Incremental Development x 2 zu 4 6 4 Conclusion aus ES 2a Da ed apu 65 ModeloftheController cen 6 5 1 6 5 2 6 5 3 7 AutoFocus Otr ctute i ew Ades SR Reli eos Eck Functionality ans 28222 UV SOR E Row Re AXttachiment etse ue pee We A E e er 7 1 General Aspects sed Du 3 as ee nS Ws C URS e Des 7 2 Modeling the sytem v Yo Re V ER Nena 7 2 1 7 2 2 7 2 3 7 2 4 Available Description Techniques Applied Description Techniques Complexity of Description Scenes Modeling Interaction x 2 2 82 u Feet iE 7 3 Development Process 12 s d ex EE RR eA Bee 7 3 1 7 3 2 7 3 3 7 3 4 7 3 5 Applhed PROCESS a apo n qo 2 am iC eme Ie aet Applied Process Support ss Applied Quality Management Applied Target Platform 2 2 2 2 252232222053 Incremental Development 74 Model of the Controller enn 7 4 1 7 4 2 7 4 3 7 4 4 Door Control x er e eck OA Baie aie dasoe qus Seat Control ooa a UserControl 6 06 05 ee ok E Rye Merger Bi dane ks Rohe OCs SHER d Er 7 5 Conclusi n 2 4 sur tert RNC ev SS Re a oe au 7 5 1 7 5 2 7 5 3 Benefits ax a aro Seb ante e CIE nde t TE Ya Weaknesses oe Desiredfeatures aa 8 MATLAB Stateflow 8 1 General Aspects ka sy ae EN eO SE Ge 3 8 2 Modeling the System v lt n Nes ag qe eee 8 2 1 8 2 2 8 2 3 8 2 4
60. of AUTOFOCUS is provided by means ofa manual examples and training documents The is no context sen sitive help system In the documentation the functionalities of AUTO FOCUS are described It covers the functionality of AUTOFOCUS but only provides basic information but doesn t go to much into depth It doesn t make it as easy as possible to open up the complete func tionality of the tool 101 102 CHAPTER 7 AUTOFOCUS Usability The usability of the tool is intuitive The basic methods are well known to semi experienced developers The user interface is mainly accessible via a mouse device only except for textfields which are ac cessible via keyboard It doesn t have a integrated desktop but uses OS windows for every windows open in the tool It happens some time that the GUI doesn t provide an optimal behavior e g that di alogs open from a window that is not the actual working area Over all the UI of AUTOFOCUS is good even if it s not as accessible as it could be 7 2 Modeling the sytem 7 2 1 Available Description Techniques Supported notations AUTOFOCUS provides four different views on the system Each of those views concentrates on different aspects in the system and supports the developers in different phases of the system development process First at all single components and the communication among each other can be represented by means of system structure dia grams SSDs see Section 7 4 Mode
61. of a system a class or a capsule Use case diagrams can be organized into and owned by use case packages showing only what is relevant within a particular package It is recommended that you include each ac tor use case and relationship in at least one of the diagrams e class diagrams show the static structure of the model Al though it is called a class diagram it may also contain other special stereotyped classes that exist in a model such as cap sules protocols their internal structure and their relationships to other elements Class diagrams do not show temporal infor mation Class diagrams may be organized into and owned by packages but the individual class diagrams are not meant to 184 CHAPTER 10 RATIONAL ROSE REALTIME represent the actual divisions in the underlying model A pack age may then be represented by more then one class diagram A model element can appear in more than one class diagram state diagrams depict the sequence of states that an object or an interaction goes through during its life in response to received messages together with its responses and actions A state ma chine is a graph of states and transitions that describes the re sponse of an object of a given capsule to the receipt of outside stimuli State diagrams show a state machine and are especially useful in modeling event driven systems collaboration diagrams show the communication patterns among a set of objects or roles
62. of the case study In this document two tests one for the centralized door locking and one for the manual seat adjustment will be described as an example But first in short our test environment shall be described Test Environment In our tests we used the From Workspace block from Simulinks library to feed in the input values from a MATLAB matrix the input data was created and maintained by an Excel sheet The model s output was sent back to MATLAB by a To Workspace block In MATLAB the matrixes could easily be edited using the Array Editor In addition we used a Function Call Generator block to trigger the model Testing the Centralized Door Locking This test describes a scenario for the centralized door locking where the driver wants to unlock the door with his key the driver s door unlocks but unlocking the right door fails and so the controller locks the driver s door again to keep all doors in the same state though this behavior is probably not really what the driver expects Table 8 2 shows the input data we used to simulate the scenario As one can see the command to unlock the door is given at t 2 and as can be seen in Table 8 3 immediately the motor for unlocking is switched on and a CAN event is sent to the right controller to tell him to unlock the door As the door unlocks in column in_T_RIEGEL 1 changes to 0 the motor is switched off and the controller waits for a message from the right controller Because the ri
63. of the description E g a operational model supporting buffered communication can simplify the description of a message handling strategy In this section a short description of the oper ational model underlying the tool is given Supported communication model Which communication models are sup ported by the tool e Synchronization concerning event scheduling I O synchronous input and output can occur during the same clock cycle clock synchronous all entities interact within the same clock cycle unsynchronized event driven other e Shared variables vs messages e Buffering message synchronous handshake blocking synchron vs non blocking usually buffered asynchronous Communication model suitable Are the notations the modeling techniques suitable for modeling the case study Timing constraints Which notations are provided to model timing con straints Sufficient realtime support Is the realtime support sufficient for modeling the case study 2 3 Development Process While the previous section focussed on what the model of a system looks like this section rather addresses the question how such a model is built In the following subsections the development process is sketched and a short description of the features process and quality management support target platform is given that were applied in the case study Furthermore some of the additional features not used but offered by the tool are note
64. operations An addon package with the name MoDe Modelbased Deployment to AUTOFOCUS exists This package ex tends the features of AUTOFOCUS With this it is possible to dis tribute the components on different CPUs Also bufferes and sched ulers can be implemented We didn t use these features because we didn t need them Reverse engineering No reverse engineering is supported by the AUTO FOCUS tool User support The AUTOFOCUS tool offers context dependant menus A 7 3 DEVELOPMENT PROCESS 109 very helpful feature is the aid when adding new transitions Here the input and the output ports of the SSD are listed and can be eas ily added to the transition by clicking a button The same applies to the variables Another useful feature is when creating or altering channels Here it is possible to auto change the Port types when the channel type is modified This helps to ensure consistency Consistency ensurance mechanisms A broad variety of consistency checks is offered by the AUTOFOCUS tool A standard consistency check can be run on the whole system This standard test can be adjusted by unchecking some options This is useful when only a specific type of test is necessary It is also possible to test only parts of the system But this I wouldn t recommend because AUTOFOCUS has then difficulty in finding some components and presents strange errors The types of consistency checks supported are Do all components have a ref
65. problems 11 2 3 Complexity of Description In this section we will provide an estimation of the size of the built model Only the part of the specification used for executing the model in the model verifier and code generation are considered This is the information repre sented by the class architecture and state chart diagrams whereas use case and sequence diagrams do not affect code generation In order to measure the complexity of the built model we counted or estimated the number of elements nodes of the diagrams and connections edges between these elements Also the number of words within one diagram will be estimated Diagrams We used three kinds of diagrams in our model of the TSG We have 7 class diagrams 6 architecture diagrams 44 state chart dia grams As these different kind of diagrams have a rather different structure we will also provide figures for them separately in the fol lowing items Nodes We interpreted a node as a graphical element within the diagrams that is not an edge or an annotation In the whole model we have 7 class diagrams We defined 8 classes those contain 11 ports where each class does not have more than 2 ports Furthermore we defined in these 7 class diagrams 10 inter faces containing 41 signals that were predefined by the case study Additionally we needed 7 signals that are not part of any of the 10 interfaces The maximum number of signals in an interface was 10 We decided not to g
66. required feature is that the whole seat adjustment may be executed only if the battery tension is high enough the speed of the vehicle is not too high and depending of the current mode the front door is open or closed We realized this with two further classes The described process with its most important classes is illustrated in Fig 6 19 on page 99 6 5 3 Attachment e automatically generated document 720KB HTML file e automatically generated source code 584KB Chapter 7 AutoFocus Percy Stocker Armin Fischer and Stefan Gersmann 7 1 General Aspects AUTOFOCUS has initially been developed in a Software Technik Praktikum at the TU Munich university and further development has been by the TU Munich and Validas Functionalities The AUTOFOCUS tool provides several functionalities to the developer It is a graphical oriented development tool for embed ded systems The main focus of AUTOFOCUS is in the modeling sim ulation validation and code generation facilities It supports version control test management and test visualization Development phases The AUTOFOCUS tool van be used in the develop ment process for in the requirements analysis design modeling and test phases It provides specification facilities so the complete prod uct specification can be mapped to the model AUTOFOCUS has the ability to generate source code from the model that can be integrated in the environment Documentation The documentation
67. responsible for all chair position changes in both manual and automatic modes Manual mode is handled only by this module and automated mode is initiated on request from BMGT module As well it provides actual positions of all sit axis on request 246 CHAPTER 12 TRICE TOOL BY PROTOS SOFTWARE GMBH Part III Requirement Specification of the Controller 247 Chapter 13 Das T rsteuerger t eine Beispielspezifikation Frank Houdeck Alexander Wisspeintner 249 Technische Universitat MUnchen TLITI Fakultat f r Informatik Hauptseminar CASE Werkzeuge f r eingebettete Systeme Wintersemester 2002 2003 Prof Dr Manfred Broy B Sch tz T Hain W Prenninger M Rappl J Romberg O Slotosch M Strecker A Wi peintner Fallstudie Tursteuergerat Eine gek rzte Fassung der Fallstudie Frank Houdek und Barbara Paech Das T rsteuerger t eine Beispielspezifikation Technischer Bericht IESE Report Nr 002 02 D Fraunhofer Institut Experimentelles Software Engineering IESE 2002 URL http www iese fhg de pdf files iese 002 02 pdf 1 2 4 5 6 Einleitung ite et e te e nase Lie EE 3 ABTA Te EE ERU LAN NILUM ALI AU ILES 4 PEE iau 4 2 2 Kurzbeschreibung der Komponente esses ener enn enn enne 4 2 3 Peripher Komponenten ic ooi he denne o WEE TREE ER 4 244 Suzeinstell ngi iiaeeteecie ttr te aeger a E E ete te ipe t ich e tan 5 2 Benutzermanagementzus i edt oe eI trat
68. simulation mech anisms Since RoseRT executes the actual software with instrumenta tion the behavior with observation is identical to the behavoir with out it Debugging Features The following features debugging of state charts di agrams are available start stop step animation of state charts break points for states transitions messages watch and manipulation of variables traces messages data time gt MSC probes inject of mes sages and some others We used this feature for modeling the TSG of the case study to validate the model behavior at run time Testing ROA RT Quality Architect RT automatic test harness genera tion and test execution out of sequence diagrams can be executed in batch mode e g for regression testing Integration with Test Real time Performance profiling Memory profiling Coverage at model and code level Trace Integration to Partner Tools like Rapid RMA TriPacific We do not use this feature for modeling the TSG of the case study Certification The Code generators are not certified by an independent cer tification authority Very strict standards like DO 178B require the application to be certified not the tools with which it was developed Rational provides a qualification kit for TestRT Requirements tracing The tool support tracing of requirements in the de velopment process Integrations to ReqPro and Doors exist Through the open API any other tool can be integrated We d
69. sitztaster The other possibility to recall a stored seat position is using the user management buttons If the driver does so the verteiler recognizes this and activates the state tasten_check where exactly the same actions take place as described above in can_check If the necessary conditions are fulfilled the seat ad justment is started in state sitztaster else the transition back to the verteiler is taken The sitztaster state itself is a bit more difficile but works about the same than the can_bus state in that it is again divided into two sub states phasel and phase2 which are executed sequen tially In phasel all adjustments to make the seat more comfort able are done and afterwards in phase2 the contrary movements 146 CHAPTER 8 MATLAB STATEFLOW poscheck_sitz_vorne mem_SITZ_VORNE speicherplatz FALSE T lauto zu schnell poscheck sitz vorne mem SITZ VORNEJ speicherplatz TRUEJ fertige motoren f rige motorenz1 X ende vc v2_c N i vie motor_sitz_vome richtung_sitz_vorne speicherplatz posche ea ea OCA E Wo auto zu schnell m U N KA motor_sitz_vorne AUS 5 i Horige_motorbn terige_ motoren if Figure 8 15 State sitz_vorne_c are performed sitztaster max motor 2 ylfertige motoren 5 Q max motor 2 Me Figure 8 16 State sitztaster phasel is again built from five parallel states one for e
70. st nkschluessel startMGMT Tuerstatus BattTS Sitzeinstellung sitzinternport ISitzposition ISi taster ISPOS FZG V externport ISifzmotoren B LOW SITZ B B ISitzposition Benutzermanagement bminternport tugrentriegeln startfunkschluessel startMGMT I T IFunkschluessel externerPort BLOW SITZ p tugrentriegeln tuerverriegeln Tuerschliesser tsinternport rstatus tuerentriegeln tuerverriegeln BattTS BattTB nd ZV_SCHL_A ZV_SCHL_R ITuersensoren IFahrzeugsensofen DC Tuerport IWin IZustand ZV_SCHL_L F_T_OFFEN IBlinken IZVMot Figure 11 14 Class Diagram TSG The third package contains the environment that was created in order to test the core system It contains five classes and simulates sensors mo tors the driver layer and the right door controller see figure 11 16 11 5 MODEL OF THE CONTROLLER 223 lt lt signal gt gt startfunkschluessel lt lt signal gt gt tuerentriegeln Integer Integer Integer Integer Integer lt lt signal gt gt startMGMT Integer Integer signal Integer T He Integer uerstatus nigger Boolean lt lt signal gt gt lt lt signal gt gt tuerverriegeln BattTS Integer lt lt signal gt gt BattTB Integer lt lt interface gt gt
71. state machine there are no short cuts for inserting states transitions etc so that everything has to be done with the mouse and it gets very time consuming Another aspect is that for more complex models it is necessary to have a big monitor to keep an overview of the model That is because for each actor and its behaviour you want to navigate through a new view is opened in a different win dow Although on the other side this is useful to be able to see both the structure and behaviour of an actor or the system A problem was also that the documentation does not cover every aspect into its fullest detail so that some issues had to be clarified with the tool developers Very helpful would have been if the tool supported the requirements elic itation We did not test the interface to DOORS so that this might have eased up some of the work Strengths e Powerfull IDE e good codegeneration e well documented generated code e small code size 238 CHAPTER 12 TRICE TOOL BY PROTOS SOFTWARE GMBH e good documentation e good stability Weakness e hotkeys only partly implemented e with complicated models you need at least a 19 monitor state ma chines e not all functions documented 12 5 Model of the Controller The TSG we modelled consists of one main actor that fulfils three main functionalities Tuerverriegelung TV Benutzermanagement BMGT and Sitzsteuerung SS In order to get our system running properly we had to mo
72. the degree of mechanization and e the quality of the development product by decreasing the amount of possible errors In order to achieves these goals however support for a model based de velopment for embedded systems should exceed Using an implementation level model Modeling the system at code level rather than at a more abstract level leads to a limited development process focusing on the implementation and integration phase Thus e g defect analysis is limited to implementation level defects This excludes simple defects like message interface incompatibility between processes executed on different nodes since those messages are de scribed as a byte block oriented bus protocol Furthermore due to the gap between the earlier phases and the implementation level even design specifications are not always related to the implementa tion This is often leading to inconsistencies between the design and the implementation Using an OO model for embedded software OO based approaches sup ply different views of the system including non executable views for early phases e g use case description interaction scenarios making consistency analysis available in those phases However those views offer only limited abstraction from the OO operational model e g synchronous method calls are used to model interaction between tasks rather than the more suitable message or signal based commu nication Furthermore additional domain s
73. the lock via the remote control or e locking the door with the key 140 CHAPTER 8 MATLAB STATEFLOW amp z blinken in KEY STATE 1 evt ZV SCHL R n ZV SCHL R 1 evt ZV SCHL A in ZV SCHL A 1 Figure 8 7 State offen If this happens a check of the battery voltage similar to the one in z a batterie will be performed except that in a z batterie there is no special treatment for a possible starting attempt If the check fails state z a kein strom is activated which sends the error message CAN B LOW KEY by a function call Otherwise if there is enough battery voltage available the model en ters the sub state a z strom in which first of all the CAN messages for locking the right door and for closing all of the windows are sent by graphical functions Next the motors for locking the bar are acti vated and the model waits up to three seconds in state a z strom 1 for the bar to unlock If this does not happen the CAN error message CAN ERROR KEY is generated and the model passes back to state a z start Else the model waits in a z strom 1 if an error message is sent by the right controller In such case the next active state is z a batterie to unlock the door again If no such event is received within one further second the doors are both properly locked and state a_z blinken is activated In this state the specified blinking operation is performed by sending two CAN messages There is a break of one second l
74. tools Nonetheless a common devel opment process independent from the tools can be established Generally in each tool application the applied process was constructed by leaving out phases or activities of this general process This overall applied develop ment process consists of three main phases Analysis The purpose of this phase is to get a better understanding of the system and to identify groups of functionality controlling the seat controlling the locking of the door and the overall user manage ment Due to restriction of notations this phase is more explicit in tools supporting additional analysis description techniques like UML use cases Nevertheless in all tools Step 2 was performed 1 Coarsely structuring the functionality of the system using use case like diagrams 2 Defining the system boundary e g actors sensors busses us ing structural diagrams 3 Exemplarily defining the functionality of the system using scenario based diagrams Design During this phase the system was generally partitioned to sup port concurrent engineering and modular development Note that this partitioning is performed on structural decomposition based on parallelly computing components generally components to control ling the seat the locking of the door and the user management but based on the functional structuring identified in the Analysis phase These steps were generally explicitly performed in all tool applica tio
75. vorne that returns the direction in which the seat should be moved the function returns SENKEN if the seat should be low ered HEBEN if it should be lifted and AUS otherwise 142 CHAPTER 8 MATLAB STATEFLOW a_z_blinken _ Jean_send_blinker 15 50 _ ime in TIME EL a z blinken 1 a evi_TIME BO in_TIME time 1 _ can_send_blinker 15 50 p Figure 8 9 State a_z_blinken manuell Figure 8 10 The five parallel states of the manual seat adjustment Afterwards the model checks if the driver s door is open because oth erwise manual seat adjustment is not allowed This is done by a call to tuer_offen a function which returns TRUE if the door is open and else FALSE If the door is closed a semaphore is used to assure that only up to two directions of seat adjustment can be active at a time If less than two directions are adjusted at the moment the adjustment of the front seat height is activated and the semaphore is increased by one Then the motors are switched on in the appropriate mode i e the appropriate voltage is put on 12 0 V for SENKEN and 12 0 V for HEBEN Inde pendent from the direction of adjustment the conditions for stopping the motor movement are checked in the successor states v2 and v3 These conditions are e the door is opened e the appropriate button is pressed no more or e the limit of the seat movement is reached The check for the resistance is realized by the fu
76. 151 t T in_SPOS_ in_SITZ_ _OF FEN W HOR V S H W HOR V S H 1 0 5 5 5 el JO 0 0 0 0 2 O 5 5 5 15 5 JO 0 0 0 0 3 0 5 5 5 15 5 1 0 0 0 0 4 0 4 5 5 15 5 1 1 0 0 0 5 0 3 wq 8 5 D 1 1 1 0 0 6 0 2v dm 5 15 5 1 1 1 0 0 7 0 1 5 5 15 5 1 0 1 0 0 8 0 1 5 5 15 5 1 0 1 0 0 9 O 1 5 5 15 qd 1 0 0 0 0 10 0 1 5 NES ANE 1 0 0 0 0 Table 8 4 Input data for the seat adjustment test t out_SMOT W HOR V S H 0 0 0 0 0 0 1 0 0 0 0 0 2 O 0 0 0 0 3 12 0 0 0 0 4 12 12 0 0 0 5 12 12 0 0 0 6 12 12 0 0 0 7 0 0 12 0 0 8 O 0 12 0 0 9 0 0 0 0 0 10 0 0 0 0 0 Table 8 5 Output data of the seat adjustment test For simplification reasons only the values for in_SMOT_W are changed which would mean that in reality only the motors that adjust the back would work The user presses three different buttons at once at t 5 but only two motors are active at one time as can be seen in the table of the output values i e the semaphor works At t 7 the back sensor indicates that the front movement limit is reached and the control logic switches off the motors At the same moment as the back motors are switched off and 152 CHAPTER 8 MATLAB STATEFLOW those for the horiozontal movement as well because the user released the button the motors for adjusting the front height of the seat are powered on 8 6 APPENDIX FAULTS IN THE SPECIFICATIO
77. AN bus State zu The state zu is waiting in its sub state z_a_start for an event that signals open the doors Such an event can be e manually opening the door with the handle see Problems with the Case Study below e opening the lock via the remote control or e opening the door with the key E evt ZV SCHL A in ZV SCHL A 2 EESTI z a kein strom evt_ZV_SCHL_Alin_ZV_SCHL_R 2 l J it PA 7 P Figure 8 4 The complete substate for locked doors If one of these events occurs the control passes to the state z a batterie Within this state it is checked in multiple steps whether the battery voltage is sufficient to open the lock bar First the function batt_low _zv is called and if its result is FALSE then there s enough battery 138 CHAPTER 8 MATLAB STATEFLOW voltage available to open the lock and the state z_a_strom is activated If the function call returns TRUE it is in turn checked whether the driver tries to start the engine If he does not the door lock can t be opened and so control goes to the state z_a_kein_strom z_a_batterie i SM Ee ES 2a altere evt KL 15START in KL_15START 0 ime in TIME z a batterie z_a batterie 1 pat low zv TRUE in KL 15START 1 gt nn ee Sarnen naar evt MOTOR LFT LM LET Tn MOTOR LFT 1 mmc evt TIM X Q in _KL_15START 0 in TIME time 1 batt low zv TRUE b
78. CT blocks These CT blocks are suitable to model and simulate continuous time systems like a drive train In detail it is possible to characterise the behavior of a controlled system via algebraic and differential equations The differential equations are solved by one of six provided real time integration methods More CT blocks together can be assembled to CT structure blocks To describe the behavior of these structure entities more precisely the functions contained in their bodies the tool provides three de scription languages block diagrams ESDL and C code With the block diagrams the embedded control system can be speci fied graphically The tool offers a large set of elements like messages 6 2 MODELLING THE SYSTEM 79 compute Min n D Bm Ei compile i Generierung einer Bin stiegenden F alnke cup PU ee LIAE C E UE AFH wenn eine Aktion ae is i ausgef hrt werden mu 1 1 soll speichern oder in aus Speicher lesen i can_m_save_1 can m pos 4 i ta out pos hor m LE i s2 spos horvin E BB er gt Spos_w 1 out pos yu r s2_spos_win D spos s 1 out pos s T i spos v o out pos v 2 5pas wlin spos h out_pos_h s2 spos Win speicher ni Eing nge aktuelle Position Speicher in ihm k nnen avers chiedenen des Sitzes tritt ein Signal Sitzpositionen abgespeichert und zu
79. Class diagram 51 visible annotations Invisible annotations State diagrams There are no invisible annotations Class diagram no invisible annotations 5 2 4 Modeling Interaction An important task during the development process is to model the interac tion between system components and objects This section shows how this task is implemented by ARTiSAN RT Studio 60 CHAPTER 5 TOOL ARTISAN REALTIME STUDIO Supported communication model A sophisticated communication model is not provided by ARTISAN RT Studio The modeling activity based on the UML standard uses a high level view of the system It is possible to give hints for the implementation team by annotations e g synchronous asynchronous method calls and timing Most of these annotations are visualized within the diagrams e g different arrowheads symbolize different message types Communication model suitable The available notations and techniques were suitable for modeling the case study Timing constraints The proprietary diagram type Constraints diagram makes it possible to collect timing constraints In sequence diagrams timing constraints can be declared for one or more steps These annotations are just for documenta tion purposes and do not affect the code generation Sufficient real time support A few special graphical elements for embedded systems are available e g busses There some generic hardware data can be c
80. DTD e SSD e STD 7 2 MODELING THE SYTEM 105 e EET Modeled aspects The following aspects have been modeled using AUTO Focus e Interfaces The interfaces have been modeled using DTDs and the port concept e Structure The structure of the model has been defined by using the SDD concept including refinement of components into more specialized components e Interaction The interaction of the components has been modeled by means of the port channel concept provided by the SDD no tation e Behaviour The behaviour of the model has been modeled using the STD notation and local variables in the SDD Notations suitable The notations provided did match the requirements for the modeling of the system Because of the modular design of the AUTOFOCUS tool system description facilities it has been easy to assign the subcomponents to the developers for further development after the system design phase Overall the concept of AUTOFOCUS provided a good way to realize the specification catalog Clearness The notation of AUTOFOCUS follows a clear concept that is eas ily understandable The subsystem decomposition is intuitive and therefore the model is clear and comprehensive The different views on the model make it possible to approach the structure with dif ferent levels of details The description of the model is divided into visible notations and structures and notations that show on as model tips when the mouse moves over
81. Diagram System Usage Model Use Case Diagram Sequence Diagram System Modes Model State Diagram System Constraints System Constraints Diagram Model Use Case Diagram Solution Dynamic Model State Diagram Activity Dia gram Interaction Model Sequence Diagram Object Collaboration Diagram Class Model Class Diagram Concurrency Model Concurrency Diagram Persistence Model Table Relationships Diagram System Architecture System Architecture Diagram Model General General Graphics Diagram Text Diagram Modeling aspects ARTISAN RT Studio supports the development process exactly as described in the RtP Mentor According to this sample process System Architecture Use Case Constraints and State Diagrams are first used to express system requirements Out of this analysis an Object Architecture emerges using Class State and Object Collaboration Diagrams For the Software Architec ture the diagram types Class and Concurrency get used At last the solution system is modeled again with the System Architecture Diagram In the following a survey of the usage of the different diagram types as suggested by ARTISAN is given Additionally all possible graphical elements for each diagram are listed A System Architecture Diagram an ARTiSAN RT Studio extension to the UML declares the software boundary with usage scenarios depicted as events flowing between Subsystems Actors and Interface Devices In fact it describes the system structure
82. Entriegeln der T r erkannt so wird der Entriegelungsvorgang abgebrochen es wird die CAN Botschaft ERROR KEY generiert 21 Nach erfolgter Entriegelung oder wenn das Fahrzeug bereits entriegelt war werden vom linken TSG soweit nicht das rechte TSG innerhalb von 1 sec die Fehler Botschaft ERROR KEY sendet die Signale BLINK 1111 und DURATION 100 gesendet Trat ein Fehler beim Verriegeln auf so wird nicht geblinkt Abschlie en des Fahrzeugs Die Fahrzeugt ren werden verriegelt wenn die T ren des Fahrzeugs entriegelt sind alle Fahrzeugt ren geschlossen sind und entweder e das Signal zum Abschlie en der T ren erkannt wird ZV_SCHL_A 10 ZV_SCHL_L 10 oder ZV SCHL R 10 e oder der Schl ssel zum Abschlie en der T r verwendet wird KEY STATE Abschlie en Um die Fahrzeugt ren verriegeln zu k nnen mu die Batteriespannung BATT mindestens 9 V betragen Unterhalb von 9 V arbeiten die Motoren der Zentralverriegelung nicht mehr zuverl ssig Ein selbst ndiges Nach Verriegeln der T ren zu einem sp teren Zeitpunkt erfolgt nicht Kann keine Verriegelung durchgef hrt werden wird die Nachricht B LOW KEY 1 gesendet Beim Verriegeln wird das Signal ZV SCHL R 10 generiert und an die Ausg nge ZENTR MOTI und ZENTR MOT2 wird jeweils die Spannung 12 V f r einen Zeitraum von mind 2 sec angelegt Sobald nach dieser Zeit das Verriegeln einer T r erkannt wird T RIEGEL 1 wird der entsprechende Motor abgestellt
83. F THE CONTROLLER 117 P2MotorSwW P2MotorDTD A2MotorSF P2MotorDTD P2MotorSB P2MotorDTD pl lt battS8 Float pbwotorsc P2MotorDTD P2MotorSA P2MotorDTD a positionSW SeatPosDTD M finishedSW Bool IT nSF SeatPosDTD I dan battSW Float finishedSB Bool db positions seat osDTO m l Figure 7 5 A screenshot excerpt of the seat control main part with the user control subsystem the plug 2 input handling and the automatons for the control of the seats for a part of the detection listed above gt From these components the lock or unlock signal is send to the main sub component DoLockOrUnlock An unlock action has always a higher pri ority than a lock signal In this component a big STD implements all the logic necessary to do the actual lock or unlock operation gt From the base state either the branch for locking or for unlocking is picked After it has been completed the base state is reentered and the next action can take place We worked quiet a bit with local variables here especially for timing oper ations Often it was necessary to save the current time from the CAN Bus to check if an action took place on time Output signals are also generated here For instance on a door locking op eration the windows have to be closed This is achieved by sending an appropriate signal on the CAN Bus The positive outcome of such a pro cess is also presented the user by fla
84. HAPTER 3 RESULT SUMMARY Chapter 4 Model Based Development Executive Summary and Picture of the Future Bernhard Schatz When looking for a definition of what model based software develop ment is or is not there is a wide range of different interpretations How ever most approaches have in common e the use of graphical representations for the system under develop ment e the possibility to describe the system or software with a certain de gree of abstraction from the actual implementation platform e the possibility to generate an executable system out of the model As shown in Chapter 3 and in more detail in the chapters of the second part current CASE tools for embedded systems do support those functionalities additionally those tools generally offer support e to describe the system using different views at least data structural state based behavioral scenario based e to hierarchically structure views e to use message or signal based communication in the operational model e to include timing aspects in the description of the system e to check the model for inconsistencies mainly on the syntactic level e g undefined identifiers type mismatches 43 44 CHAPTER 4 MODEL BASED DEVELOPMENT e to simulate the system or software at the level of the description Implicitly or explicitly most model based approaches aim at increasing both e the efficiency of the development process by increasing
85. I Logix YERSION 3 1 LE Created SGE_1 2 SGE_1 terninated Figure 9 3 Rhapsody main window user interface Usability Rhapsody isn t a classical Windows tool it was developed for the Unix platform One resulting disadvantage is that the clarity of the tool is afflicted with multiplicity of open windows But there is the central workarea browser to navigate through the specific functions see figure 9 4 The orientation is also given by the project window which is depicted in Figure 9 3 The user interface of the modelling tools looks like a typical graphic editor so the modelling tools are in tuitively useable After incorporating into the tool Rhapsody in Mi croC offers many possibilities to realize test and simulate the project 9 2 Modelling the System 9 2 1 Available Description Techniques Supported notations The supported diagram types of Rhapsody are activity charts state charts flow charts use case diagrams and sequence diagrams 9 2 MODELLING THE SYSTEM 159 ACHSE S CONTROL 49 ACHSE V CONTROL 49 ACHSE W CONTROL af TUERSCHLOSS a9 TUERSCHLOSS C2 Figure 9 4 Workarea browser Sequence diagrams Sequence diagrams represent the interaction be tween specific components They resemble the UML sequence diagrams An example for a sequence diagram is depicted in Fig 9 2 In the sequence diagrams the axes stands for the components the ar rows between the axes are messages that th
86. N TRALVERRIEGELUNGSMOTOR which cares about controlling the door 176 CHAPTER 9 RHAPSODY IN MICROC SITZVERSTELL TASTER SITZSTEUERUNG SITZEINSTELLUNG_MANUELL Figure 9 13 Activity chart SITZSTEUERUNG SEMA 90 PROCESS_HOR 0 PROCESS_H 0 PROCESS V 0 PROCESS_S 0 PROCESS_W 0 MANUELL BACHSE_HOR CONTROL ACHSE_ _CONITROWACHSEL_W CONTF GACHSE VW GACHSE Hj C EIL tr BATT gt 101 not CT_OFFEN F2G_ gt 5 _GROESSER_S_KMH Figure 9 14 State chart SITZEINSTELLUNG_MANUELL CBATT lt 101 SENA 0 TUER_ZU BATT_LOW 9 5 MODEL OF THE CONTROLLER 177 ZEN DEN TRAE vERRII ZENTR MOT2 GTUERSCHLOSS C2 ENSENSOR GRIFF Figure 9 15 Activity Chart Tuerschloss locking engines A screenshot of the activity is shown in Figure 9 15 In the component TUERSTEUERUNG you must especially look for that locking the door should have top priority Therefore all states which in volved in locking the door are nested in a hierarchy that have a transition to the unlocking state So it s guaranteed that you can unlock the door ev erytime The many requirements result in a complex diagram which is shown in Fig 9 16 178 CHAPTER 9 RHAPSODY IN MICROC 1000 HRRTEN EBATT lt I KL_15 anddlly ART Ina START r r tr FUNK_OEFFNE Figure 9 16 State chart TUERSCHLOSS Chapter 10 Rational Rose RealTime Anis Trimeche Abdellatif Zaouia Hongkun Jiang
87. N 153 8 6 Appendix Faults in the specification The first specification included several faults and uncertainties First there were some mistakes in the output data in the chapter about the door locking 5 4 The motors for locking the doors are mapped to the according plug and so it must be S1 ZENTR_MOTI as well as S1 ZENTR _MOTZ here the S1 was missing Furthermore the commands to control the opening and closing of the win dows lacked now in the second version they are included WIN_VL_CL for the left side and WIN_VR_CL for the right one Next in the subsection about the behaviour for unbarring the doors there was a contradictory specification of the values to use for barring unbar ring the doors The command xF_OFFEN doesn t exist in the corrected version it is T _OFFEN and signals if the door is either opened or not The signals to open the doors were in the first version ZV_SCHL_A ZV _SCHL_L and ZV_SCHL_R but here only ZV_SCHL_A and ZV_SCHL_R can be used The signal ZV_SCHL_L is generated in the exceptional case here it was at first wrongly ZV_SCHL_R i e the command for opening the doors comes together with a trial to start the engine For all of these three signals the text says 01 binary is the right value to unbar the doors but in the table where these commands and their possible values are de scribed it is the other way round So we decided to keep the values of the table which means that we send 10 binary to u
88. PU On a 4 or 8 bit CPU the size would even be smaller Our model was not optimized in terms of code size With a little work the code could even be smaller If the test drivers are created we have about 11464 Lines of code and the size of the binary is about 109 kB Readability of code The readability of the C code is good And the struc ture is intuitive For all datatypes seperate files are created This way the reuse of these code components is ensured Also helpful com ments are created to increase the readability of the code 7 3 5 Incremental Development The incremental development process is supported by AUTOFOCUS But one has to be careful in the design phase to take this into account when de signing to structure With a little work there we came up with a model that enabled us to reuse some STDs This was especially helpful when upgrad ing the seat control from two to five axis Often it was possible to copy an existing Transition and to adjust it a little bit Reuse The DTDs could be derived from the specification Also the struc ture could be transferred to the SSD environment This enabled us to stick very closely to the specification which made the testing eas ier The tricky part was the design of the automatons Here we had to take the requirements from the specification and to simulate them using SSD and STD structures Restricted changes As it was possible to model our system very similar to the specification we di
89. ROCESS 167 e semantic consistency As there is no semantic connection be tween created sequence diagrams and the state machines There can made no statement concerning the semantic consistency Component library Modelling with components administrated in libraries is supported by RiMC But predefined components are not available Development history RiMC records the history of all created files in its database The files can be checked in and out with using a locking mechanism So the files accordingly can be checked out just in Read Only and Update mode The last updated version of each file re mains in the database Therefore a modified file can be substituted by the last version in the database at any time Unfortunately not all created versions of each files can be recovered what would be helpful for incremental development Moreover several other configuration management tools like ClearCase or CVS are supported 9 3 3 Applied Quality Management In this subsection all performed validation and verification tasks that en sure that the model is correct with respect to the specification are included Additionally the tool is characterized along the criteria of quality man agement While modelling the case study we mainly used the techniques host simulation with graphical panels in association with test vectors Target testing was not used because there was no hardware target available in the case study Host Simulatio
90. TUM INSTITUT F R INFORMATIK CASE Tools for Embedded Systems Bernhard Sch tz Tobias Hain Frank Houdek Wolfgang Prenninger Martin Rappl Jan Romberg Oscar Slotosch Martin Strecker Alexander Wisspeintner TUM 1I0309 Juli 03 TECHNISCHE UNIVERSIT T M NCHEN TUM INFO 07 10309 0 1 FI Alle Rechte vorbehalten Nachdruck auch auszugsweise verboten 2003 Druck Institut f r Informatik der Technischen Universit t M nchen CASE Tools for Embedded Systems Bernhard Sch tz Tobias Hain Frank Houdek Wolfgang Prenninger Martin Rappl Jan Romberg Oscar Slotosch Martin Strecker Alexander Wisspeintner and contributions by Christoph Angerer Martin Glaser Christian Merenda Josef Maran Martin M ssmer J rgen Steurer Percy Stocker Armin Fischer Stefan Gersmann Maria Bozo Karin Katheder Thomas Off Bastian Best Julian Broy Gerrit Hanselman Peggy Sekatzek Anis Trimeche Abdellatif Zaouia Hongkun Jiang Karin Beer Christian Truebswetter Alexander Woitala Clemens Lanthaler Petr Ossipov Tania Fichtner July 24 2003 This work was in part supported by the DFG projects KONDISK IMMA InOpSys Inkrea and SPP 1040 under reference numbers Be 1055 7 3 Br 887 16 1 and Br 887 14 1 Br 887 9 and InTime SPP 1064 Contents Introduction LD AWENE W noe age fe a ern 12 What This Report Does Not Aim At 13 What This Report Does Aim At 2 2 2 2 2 1 4 Acknowledgments 23 2 vr R
91. Type of notation Most of the notations of AUTOFOCUS are represented graphically SSDs are drawn as boxes in an editor and channels can be connected through drag and drop With every channel two ap propriate ports are created and shown in the editor The attributes of channels ports and components can be edited in pop up dialogs Local variables are represented in table form The timelines and actors in EETs are pictured in an editor and also the messages between them can be drawn by drag and drop The order of the transmitted mes sages can be shown with a dashed line Also STDs can be edited and created in an editor Transitions can be dragged from state to state there and edited in a dialog window Only the DTDs cannot be edited graphically they are shown in a text editor where the constants types and functions are stored sequen tially All types of views on the model are represented in the project browser in tree form Hierarchy Each SSD STD or EET can have a substructure so it is possible to create blackbox views of parts of the model SSDs either have a subcomponent which consists of one or several components having the same input and output ports as their superior component STDs may have subcomponents They communicate via channels the input and output ports have to match with those of the parent component 7 2 2 Applied Description Techniques Applied notations The following notations diagrams have been used in the model e
92. User support Rational Rose RealTime provide user support in form of Wizards and tools 1 Component Wizard helps you to quickly create C and C Ex ecutable components 192 CHAPTER 10 RATIONAL ROSE REALTIME 2 TargetRTS Wizard simplifies the activities of building config uring managing and customizing the TargetRTS libraries and build environment we did not use this feature for modeling the TSG of the case study 3 Aggregation Tool enables you to quickly create aggregate and composite associations An aggregation association is a special form of association that specifies the whole part relationship be tween an aggregate whole and the component part Consistency ensurance mechanisms The tool offers mechanisms to find build errors in the model The build errors tab contains a location column that provides the class code segment name pair The Context column provides the context of the problem The Message column gives a description of the problem These messages are taken directly from the compiler error stream and therefore reflect the accuracy of the compiler that you use Further errors within your code segments may lead to errors being reported in system generated files Double clicking on an error or warning on the Build Errors tab brings you to the location in the model where the problem occurred The consistency in Rose Realtime can be realized in some degree e Rose Realtime provides syntactic consistency e g t
93. a consistent state at every time during the development process Therefore it is possible to restructure the models easily without an tremendeous impact The quality of the code synch features could not be evaluated because the system has not been implemented yet 5 4 Conclusion In the following we give a short summary of the strengths and weaknesses of the tool ARTISAN RT Studio is a very professional implementation of the UML standard Besides there are some enhanced and useful notations which enlarge the capability of expression of the modeler The usability of the tool is very good and intuitive Moreover the consequent interconnection between different diagrams even in textual descriptions is a excellent fea ture The provided functionality is professionally realized On the other hand there s no elaborated real time support available ARTISAN RT Studio is not a complete development tool for embedded systems Other applications have to be used in order to cover all imple mentation aspects Although the functionality to synchronize source code with a model exists and simple code editing operations can be done within ARTISAN RT Studio a real coding development environment is necessary Unfortunately the code generators only produce class skeletons without using all the other existing informations of the model Though our model was not exceedingly large some operations like merging models became increasingly slow All in all we real
94. a memory button is pressed or a radio key is used to open the doors Then the seat is moved to the position speci fied by the memory This happens in two different ways If the signal comes from the radio key then all axes are adjusted to the position wanted as fast as possible Otherwise the seat adjustment is executed in two phases first all movements are done to make the seat more comfortable and second the wished final position is reached This time it is presumed that the car drives with less than five km h and the battery voltage is sufficient 8 5 2 Components and their Functionality Centralized Door Locking The centralized door locking gets the input signals that are specified within the case study These signals report e the states of the doors and the lock 8 5 MODEL OF THE CONTROLLER 137 e the different locking commands e the state of the ignition the engine and the battery voltage Depending on the state of the doors and the lock the centralized door locking controls the locking motors the blinker and the window lifts In case of an error it sends the right messages over the CAN bus The model of the centralized door locking consists of the two super states zu and offen which are in turn assembled from sub states Some of these sub states themselves are again put together Furthermore the model includes several graphical Stateflow functions which realize the control of the locking motors and the communication via the C
95. ach axis of adjustment The axes are adjusted in the order horizontal back seat casing seat front and back But only up to two direc tions may be moved at one time For phasel the adjustment of the front of the seat in sitz_vorne_1 is explained exemplarily the other axes work accordingly First the actual position of the seat and the position saved in the memory are compared in the state idle v 1 to see if the seat 8 5 MODEL OF THE CONTROLLER 147 Figure 8 17 State phase_1 needs to be lowered If this is not true a transition to state the final state ende_v_1 takes place see nn ri ae a sitz_vorne_1 idle_v_1 richtung_sitz_vome speicherplatz SENKEN 5 E i lauto_zu_schnell i Be Imax motdrs a nd 4 vid lz gt v2_1 Imotor_sitz_vome SENKEN d ame 1i UT UK cpu er ee E ende v 1 entry max_motor max_motor 1 fertige_motoren fertige_motoren 1 j Jis zu schnell Pas eee PCC ORE OCUEROOSOOOOOOCOCCOOCOCUCOCCUCOECUCUOCCOCOCCCCOOCCCOUCCOCCOOTCOOOCCORCCCOEOORCOO OSE Figure 8 18 State sitz_vorne_1 Otherwise the model checks the velocity of the car and tests with the help of the semaphore max_motor whether the states with higher ranks have already finished their adjustment In v1_1 the modus SENKEN of the seat adjustment is chosen the right volt age is switched to the corresponding motors with the function motor_sitz_vorne and state v2_1 is activ
96. ach component This had taken the most time in the developing process Furthermore we created different panels to check the system whether it agrees with the specification by simulating different user inputs and testing the reaction upon it In this phase we often had to jump back to the state charts and redesign these to gain the desired functionality 9 3 2 Applied Process Support In this subsection all aspects that helped us during the development pro cess will be discussed 166 CHAPTER 9 RHAPSODY IN MICROC Simple development operations The tool provides several simple devel opment operations e g it is possible to cut and paste parts of a dia gram This is very helpful particularly with regard to the reusability of the model of one axis Beyond this the developer has the possibility to import parts out of other projects Unfortunately a Redo function was missing Furthermore there is a possibility to change the value of variables globally but the way of defining scopes is not very intu itively Complex development operations The developer is able to integrate a com munication protocol This can be done by including a library into the model To create a system which runs on distributed hardware com ponents Statemate supplies help Statemate can be easily integrated with RiMC Reverse engineering RiMC doesn t support Reverse engineering This would mean creating statecharts out of source code User support An assis
97. achine The state machine is a special type of class that does not fo cus on computations but on control flow Therefore the main level of description the state diagram does not describe how data but how control is passed To model control flow a state machine consists of a finite number of states and transitions between them see Fig 6 5 on page 78 For a state there are three actions the entry action the static action and the exit action The static action is executed period ically until the state is left Whether the state is left or not depends 78 CHAPTER 6 ASCET SD on the condition of the transition This condition is tested periodi cally by a trigger When the condition is true the transition action will be executed first and then the target state will be jumped to A state can be declared hierarchical and contain sub states that are also associated over transitions The history option provides the means to determine the destination substate of a transition to a hierarchy state based on past activities If a hierarchy state has got a history the tran sition ends in the substate that was active most recently and not in the start state SOME STATE Entry Static Exit Priority number 4 trigger trigger CONDITION CONDITION trigger TRANSITION TRANSITION Figure 6 5 Example of a statemachine CT blocks As quite special structure entity ASCET SD features the con tinuous time blocks in short
98. actor s internal and external ports or from its service access points Type of notation As Trice uses ROOM notation main elements of it are actors and protocols and each actor s behavior is modeled as finite state machine As well data classes and sequence diagrams are present All representation types of the notations are graphical The tool has various graphical editors each for a specific function actor behav ior editor actor structure editor hierarchical structure browser con figuration editor deployment view diagram tracing view message sequence chart view Also see pictures in chapter 5 Hierarchy Hierarchical structuring is supported by Trice in the structure and the behaviour modelling notations The hierarchical structure of the system means that actors can be formed by adding other actors together which considerably improves clarity and enables the break down of complex components into components which are easier to 230 CHAPTER 12 TRICE TOOL BY PROTOS SOFTWARE GMBH understand As state machines can be very complex ROOM intro duced a way to reduce this complexity significantly by means of hier archy and abstraction Each state of a hierarchical state machine can contain a whole state machine and so on recursively 12 2 2 Applied Description Techniques Applied notations For modeling the case study we mainly used the struc ture and behaviour editor and followed the recommended modeling approach So for the s
99. ad only mode An automatic backup process could have preserved us for doing the same work twice Once the system crashed and we had to restore a backup which we made some time before At last an extended library is preferable You have the ability to store your own components but a larger standard library would be helpful 122 CHAPTER 7 AUTOFOCUS Perhaps some of those features are implemented soon and the specified errors are eliminated Then AUTOFOCUS will be a more interesting tool for modelling as it is anyway Chapter 8 MATLAB Stateflow Maria Bozo Karin Katheder Thomas Off 8 1 General Aspects Functionalities Stateflow is a graphical design and development tool for control logic that can be used together with Simulink Stateflow pro vides functionality to design model and develop finite state machines The created models can be simulated and tested with input data from Simulink but Stateflow itself provides no functionality to automati cally generate test cases Further analysis is possible with auxiliary tools e g a model coverage tool see 8 3 3 For test management one can run a batch of simulations via the MATLAB command line Us ing Stateflow Coder one can also generate code in C C and ADA There are also different possibilities to document your model for ex ample by using special documentation dialogs in Simulink generat ing HTML reports or print books from your Stateflow model MAT LAB itself provides no ow
100. agrams allow graphic mod elling Hierarchy ASCET SD supports hierarchical structuring very well At the top level stands the project containing several modules Classes and state machines are part of the 3rd level The components of the 3rd level can be nested very flexibly Hence classes are able to comprise subclasses and the state machine s hierarchy states can contain sub state machines But it is also possible to nest classes in state machines and vice versa Fig 6 7 on page 81 gives an example 6 2 MODELLING THE SYSTEM 81 Modul 2 Moduln SoS ee e E T 1 Figure 6 7 Example of hierarchical structuring In addition to this hierarchical structuring mechanism the tool provides a component called Hierarchy The hierarchy is a box that can collect parts of a block diagram to make the diagram clear and easier to read This component can also be nested 6 2 2 Applied Description Techniques Applied notations All available description techniques except for CT blocks have been used We had no controlled system to model hence no CT block was necessary Modelled aspects With the provided notations all relevant aspects like be havior structure interaction and interfaces of the system could be modelled Notations suitable The notations we used to model the case study were very suitable ASCET SD offers pretty much of them and every one could be used to model a special part of the system Particularly the three av
101. ailable description languages allowed a very comfortable but also fast and efficient modelling The biggest part of the system we have modelled with block diagrams The block di agrams have the advantage that they are very clear and readable all their components can be configured with dialog boxes and almost everything can be done by drag and drop The diagrams are most suitable for modelling data flow and small logical and arithmetic ex pressions But if the operations get to complex it is easier to use the textual notation like ESDL and C 82 CHAPTER 6 ASCET SD Clearness The notations allow to build clear and readable models The reason for that is the possibility to build a graphic model and to struc ture the model hierarchically Missing notations The concept of semaphores is missing It would have been very helpful to control the access to variables messages and especially for our case study to make sure that at most two seat axes are adjusted 6 2 3 Complexity of Description Views Our model has 23 views These are 1 project 3 modules 16 classes and 3 hierarchical sub states of the state machine From the view of the project every other view can be reached Nodes As nodes we have counted 3 modules 54 classes 23 states 2 tasks and 3 processes that makes a total of 85 The maximum number of nodes used in one view is 17 the average is about 3 7 Edges The whole model comprises about 150 associations and transitions
102. ality Management 11 3 4 Applied Target Platform 11 3 5 Incremental Development TE Conclusion user an eh Ge a tee are aad 11 5 Model of the Controller 2 2 22222 2222 11 5 1 Packages and Classes u 4 223 aig wk 2 22235 11 5 2 Architecture om onen 11 5 3 Design of the behavior 12 Trice Tool by Protos Software GmbH 192 1 General Aspecist i etuer Sele Sue ge CR Am ADR 12 2 Modeling the System 222 serine 97 En Gye Ae Tn 12 2 1 Available Description Techniques 12 2 2 Applied Description Techniques 12 23 Complexity of Description 12 2 4 Modeling Interaction 2 222222 12 3 Development Process u ghe cx ae Bene 12 3 1 Applied Process u o eom 12 3 2 Applied Process Support is xut ae 33 22 12 3 3 Applied Quality Management 12 3 4 Applied Target Platform 12 3 5 Incremental Development T2 4 Conclusion es pere ns nee 12 5 ModeloftheControllr III Requirement Specification of the Controller 13 Das Tiirsteuergerat eine Beispielspezifikation 196 200 201 201 202 202 208 210 212 214 214 214 217 219 220 220 221 221 223 225 227 227 229 229 230 231 231 232 232 232 234 235 236 237 238 247 249 CONTENTS Chapter 1 Introduction In this report we show how eight different CASE tools for embedded
103. als the use of conditions was fully suitable Numeric semaphores in our model were implemented by shared in teger variables Timing constraints Thus timing constraints are used in the specification stage they can be specified with sequence diagrams Timing can be modelled with constructs like delays timeouts and scheduled ac tions In our model we used delays to realize the timing constraints This usage of delays is available in the state charts we primarily used Sufficient realtime support The whole time model of Rhapsody is based on the OSEK time model and so by default Rhapsody uses the system timer but it s also possible to adjust the timing of the model you have created to a counter you need For this you must set the system timer counter option in the compilation profile So the support for realtime models is well especially due to the time model is based on the OSEK time model that enables a controlled real time execution of several processes which appear to run in parallel 9 3 DEVELOPMENT PROCESS 165 Therefor the OSEK time model provides a defined set of interfaces for the user These interfaces are used by entities which are competing for the CPU The two types of entities are interrupt service routines and tasks In our model we used the task based variant 9 3 Development Process In the following section a description of the features that were applied in the case study is given 9 3 1 Applied Process The dev
104. alue 4 0 SeatPosValue 3 0 SeatPosValue 5 0 canMsgln CyclicCanCMsallM CLkeep 12 0 trye 1000 0 0 KSingerted WWControl WCSkeep WCSkeep UMEmpty DState DS closed DSclosed plug1Msgln P1Msglin present present present present present present present present KSLock userManagementCommand UMsavePos1 plug2MggOutP2MsgOut npvoltage novoltage novoltage noyolfage novoltage novoltage plug2MsgIn P2MsgIn SBNdne SBNone SBNone SBNone SBNone SeatPosValue 2 0 SeatPosYaluet1 0 SeatPosValue 4 0 SeatPosValue 3 0 SeatPosValue 5 0 canMsgln CyclicCanCMsallM CLkeep 12 0 trye 1000 0 0 KSingerted WWControl WCSkeep WCSkeep UMEmpty DState DS closed DSclosed plug2Ms gOut P2MsgOut npvoltage novoltage novoltage novolfage novoltage novoltage canUserManagement UMsavePos1 plug2MsgIn P2MsgIn SBNane SBNone SBNone SBNone SBNone SeatPosValue 2 0 SeatPosValue 1 0 SeatPosValue 4 0 SeatPosValue 3 0 SeatPosValue 5 0 canMsgln CyclicCanCMsallM CLkeep 12 0 trye 1000 0 0 KSingerted WControlWCSkeep WWCSkeep UMEmpty DState DS closed DSclosed plug2Ms gOut P2MsgOut npvoltage novoltage novoltage noyolfage novoltage novoltage plug2Msgln P2Msgin SBNane SBNone SBNone SBNone SBNone SeatPosValup 2 0 SeatPosValue 1 0 SeatPosValue 4 0 SeatPosValue 3 0 SeatPosValue 5 0 canMsgIn CyclicCanCMsgIh CLkeep 12 0 true 1000 0 0 KSingerted VControl CSkeep WCSkeep UMEmpt
105. amp sollwert_w int amp s int offen int 2 1 amp bsollwert s int amp sollwert_v int sollwert_h int 199 W S1ASPort S1ASProtocol W CASPort CASProtocol I S2ASPort S2ASProtocol W SBPort BSProtocol W Controller1 CSitz vor zurueck E Controller2 CSitz steiler flacher Controller3 CSchalung enger weiter W log Log T rSchlo Design Controller4 Cflaeche_hinten_sinken_heben LII ControllarS Cflaeche vorne sinken heben e x Capsub gt gt lt lt Capsule gt gt flaeche_hinten_sinken_heben SitzEinstellung from TSGDesign i Controller4 Cflaeche_hinten_sinken_heben Wi SBPort BSProtocol S14SPort S1ASProtoco Wi CASPort CASProtocol B S2ASPort S2ASProtoco i timer Timing Wi log Log ir lt lt Capsule gt gt Sitz steiler flacher E 1l I Controller2 CSitz steiler flacher4 lt lt Capsule gt gt flaeche vorne sinken heben W Controlers Cflaeche_vome_sinken_heben lt lt Capsule gt gt Sitz_vor_zurueck W Controlleri CSitz vor zurueck lt lt Capsule gt gt Schalung_enger_weiter Controller3 CSchalung_enger_weiter This State diagram consist of 7 States When the driver lock the car doors the sate machine go from the en
106. another input signal that had to be queried If this signal hadn t existed it would have been possible to model an own timer component that had been producing such a signal Then the clock cycle would have had a huge impact on the timing issue Sufficient realtime support The realtime support of AUTOFOCUS has been sufficient for the modeling of the case study It is possible to simulate cases and to visualize the way and timing of the messages through the SSDs and STDs 7 3 Development Process 73 1 Applied Process We didn t use the Extended Event Traces EET in the Analysis phase be cause the interaction between the Components was pretty obvious So we didn t want to waste any time in here since the EETs can t be used in the 108 CHAPTER 7 AUTOFOCUS later work The first thing we did was to define the interfaces of our sys tem to the environment There were basically three interface definitions needed For the CAN Bus and the two plugs In AUTOFOCUS channels are used to model interaction So we decided to use three input and a few more output channels The driver can then listen on the output channels and then for example write the data back on the Can Bus The input chan nels are split up inside our TSG and linked to all components that need data from outside the system We wrote our own datatypes for the chan nels Otherwise we would have had much more channels The next step was to model the structure of the system This was don
107. architecture diagram Interfaces and signals should be defined in separate packages in order to increase modularity For complex systems also the different parts of the system can be split up into packages Interaction between the single components of the system is described by sequence diagrams But no code is generated out of sequence dia grams Instead architecture diagrams and state chart diagrams define the interaction As mentioned before architecture diagrams specify the structure of the system hence also the communication structure that is required for the interaction How a single component interacts with its environment i e how its behavior is like is specified in state chart diagrams Keep in mind however that state chart diagrams always belong to a class description not to a single part During sim ulation sequence diagrams can automatically be generated from the model verifier and they can be compared with the sequence diagrams that have been created manually Type of notation The idea of UML2 0 is to represent the system in terms of graphical views Graphical modeling can be used throughout all diagrams in Tau Two exceptions exist use case and state charts The former uses diagrams for representing relationships between use cases and text for their content The graphical modeling of state charts is extended by source code annotations for the input output with the environment for the control of local variables and the workin
108. ardless of the sup ported approach e g stability speed suitability of menus or dialogs etc Even with differences in both the level of model based support as well as criteria like stability in general the usability was rated from good to very good and intuitive This can be at least partly related to the fact that all par ticipants received training in applying the tool prior to the modeling task Nevertheless all tools had some potential for improvement for example re garding stability window managing or speed 3 2 Modeling the System Generally for an embedded system the interactive behavior of the system or its components plays a more important role than the complexity of its data structures Therefore a central aspect of a development tool for em bedded systems is the modeling these interactions to treat them at a higher level of abstraction than e g in terms of method calls between objects or procedure calls to the operating system to access the communication bus or to activate a timer In general all of the selected tools model an embedded system as a collection of individual reactive components communicating by some form of message or signal exchange The environment is accessed by receiving messages from sensors and sending messages to actors Each component has an associated behavior describing its input output relation in form of internal computational data flow or state machine the behav ior is triggered by the recept
109. ated This state is left as soon as the saved position is reached or the car gets too fast Then the motors are turned off and control passes over to ende _v_1 where the semaphores rax motor and fertige motoren are increased When all adjustments to the more comfortable direction have been executed i e the value of the semaphore fertige motoren has become five the state phase is left max motor is set back to zero and phase2 becomes active This state s structure reflects the state phasel only the axes of the seat adjustment are moved in the other direction everything 148 CHAPTER 8 MATLAB STATEFLOW else works identically At the end of phase2 if everything is completed control passes back to the verteiler State speichern This state realizes the possibility to save seat posi tions within four memories Because this is a quite simple task the state itself is built up quite simple If speichern becomes active it just saves the actual values of the five axes of adjustment into the appropriate memory and sets a boolean flag which indicates whether a memory has already been used before or not because empty memories can not be restored by can or sitztaster After that a transition back to the initial state of the user management the verteiler takes place 8 5 MODEL OF THE CONTROLLER 149 8 5 3 Tests We have performed a number of tests for all three parts of our model to assure the correct implementation of all aspects
110. ately However we used only one target in our example project Reverse engineering There is no support for reverse or roundtrip engi neering User support Trice offers interactive formal methods which can e g give advice during the modeling of hierarchical state machines We didn t use this feature in our test project Consistency ensurance mechanisms e syntactic consistency e g type correctness unambiguousness of identifiers executability Trice offers the syntactic consistency checks during typing of the action entry exit code and choice point conditions using differ ent colors e semantic consistency e g compliance between the sequence di agrams and the state machines State machines must be consistent with the generated sequence charts from the debugging mechanism Semantic consistency is only given after compiling the model If changes are made in one of the State machines after generating the sequence chart you must regenerate the charts because the old ones aren t longer ac cessible then Little checks are also provided when modeling a state machine Component library The Primitives described above are one means of us ing predefined components with Trice External users can provide their own components which may have program code in multiple languages and their own graphical user interface for tracing An other means for predefined component libraries is the actor drag amp drop feature also described abo
111. att low zv FALSE can send b low key 1 Figure 8 5 Statez a batterie Otherwise if the starting attempt is finished or the engine runs the model waits one second and checks the battery voltage again If it s still too low the above described treatment takes effect and state z a kein strom is the successor state Else the transition to z a strom results In the state z a kein strom the error message CAN B LOW KEY is sent by calling the function can send b low key and the initial state z a start is reentered The state z a strom is responsible for unlocking the doors Therefore it first sends a CAN message by a function call on can send zo schl _I to the right controller notifying it to unlock the right door The controller then activates the motors which unlock the door and waits instatez a strom 1 up to three seconds for the lock bar to open If the bar opens the controller switches off the motors and waits another second in z a strom 2 for a CAN ERROR KEY event that might be sent by the right controller If such an event occurs the controller checks whether the door opening command was given from inside the car and in such case moves to state z a error If no such event is sent the unlocking of the door was performed and 8 5 MODEL OF THE CONTROLLER 139 2_a_strom a 5 ne 1 motor_zentralverriegelung AUF hime in TIME ERIERSA a gt O in za strom n_T_RIEGEL 1 7 T J FA Q fi 1
112. ave oe Dc alegre Bars ae Preface Assessing the Tools 21 General Aspects vu voce ead UR SES UE acies 2 2 Modeling tlie System 2 u 042 82 Da 8 2 2 2 1 Available Description Techniques 2 2 2 Applied Description Techniques 2 23 Complexity of Description a wee PES 2 2 4 Operational Model 4 2x S 2 3 Development Process ss up FE WR Sed Se a EH 2 3 1 Applied Process cc scere er Ste Y xe RN et 2 3 2 Applied Process Support 22 2222 2 2 3 3 Applied Quality Management 2 3 4 Applied Target Platform 2 3 5 Incremental Development 222252 22 21 223 24 Conclusion 2 sux T er 20a VIE V ee 25 ModeloftheController llle Result Summary 3 1 General Aspects 324 262 2 pub WG an a Sisk Functionality see E hs een rer 3 12 Development Process de 22 83 2 104 3 13 Documentation 00000004 3414 Usability u SoS doe x ran dh 3 2 Modeling the System zs lY ve aed ew lee oes Es 3 21 Available Description Techniques 3 10 10 11 11 13 15 15 16 16 17 17 18 18 19 19 20 20 21 21 21 II 3 2 2 Applied Description Techniques 3 23 Complexity of Description 3 2 4 Operational Model 3 3 Development Process ax ws 3 3 1 Applied Process ss tos eats 3 32 Applied Process Support 3 3 3 Applied Quality Management 3 3 4 Applied Target Platform 3 3 5 Incrementa
113. ben 2 5 Benutzermanagement Ohne Benutzermanagement mu jeder Fahrer Sitzposition vor jedem Fahrantritt berpr fen und ggf neu einstellen Das Benutzermanagement nimmt dem Fahrer diese Aufgaben ab indem es diese Einstellungen speichert und bei Wiederbenutzung des Fahrzeugs durch denselben Fahrer dessen vorherige Einstellungen wiederherstellt Dazu stehen den Benutzern eine Speicherungstaste und vier Zifferntasten zur Verf gung die vier benutzerdefinierten Einstellungen entsprechen Die Einstellungen der Platze eins und zwei werden abgerufen wenn a der Benutzer die entsprechende Zifferntaste dr ckt oder b der Funksender mit der Benutzerkennung eins bzw zwei verwendet wird Die Einstellungen der Platze drei und vier k nnen nur ber die entsprechenden Zifferntasten abgerufen werden Zur Speicherung der ggf ge nderten Einstellungen mu der Benutzer die Speicherungstaste dr cken gedr ckt halten und anschlie end die Zifferntaste des entsprechenden Speicherplatzes bet tigen Das Benutzermanagement wird in Abschnitt 5 3 n her erl utert 2 6 T rschlo Zum Auf und Abschlie en des Wagens von au en kann der Benutzer wahlweise das T rschlo in der Fahrer bzw Beifahrer T r verwenden oder aber einen Funksender einsetzen Die Verriegelung der zwei T ren wird daraufhin gemeinsam ge ffnet bzw geschlossen Die ffnung und Verriegelung des Kofferraums wird vom Kofferraum Steuerger t bernommen Das ffnen der T ren von i
114. ble set TRUE Figure 6 16 Functionality of the CAN connection time cycle Now the array respective the message is complete and has to be sent Our implementation is only a very simple simulation of a CAN connection therefore the message is not really sent The sending process is simulated by setting a boolean variable TRUE Af ter the messages has been send all variables used to generate this message and the mentioned array are reset The procedure begins anew Centralised door locking The centralised door locking system of the con trol unit we had to implement is realised as a state machine There are three main states One of them is the start state it is active just for a moment when the system booted up Immediately after it will be checked if the doors are locked or unlocked As the case may be the start state will be abandoned and the new active state is either door locked or door unlocked see Fig 6 13 on page 92 Another main states has the job to detect an inconsistent state The machine goes to the inconsistent state if a door is opened and locked at the same time In this case the door will be unlocked immediately independent of the current active state see Fig 6 13 on page 92 The last of these three main states is a hierarchical state It contains seven states three of them are likewise hierarchical If the door is locked the active state of the state machine is door locked When an unloc
115. both are target independent languages Therefore you can create code for specific targets with the appropriate compilers Code size We used the compiler delivered with MS Visual Studio 6 0 to generate code for i386 architectures Without optimization and in cluding the whole environment we got a 90kB executable file By optimizing code size we obtained 81kB Readability of code The C source code produced by Tau had a size of 981kB There are a lot of comments describing every node of the dia grams of the model Some long references and the fact that we have nearly 1000 nodes makes the code very long But nevertheless it is well structured The code can be understood but modifying is quite difficult because of the flabbergasting number of code fragments 220 CHAPTER 11 TELELOGIC TAU 11 3 5 Incremental Development Reuse Throughout the whole development process we incremented the functionality of our system starting with one axis and one button All the system behavior is described by state charts To add more functionality we added new state charts to the model and modified or extended the existing ones We often used copy and paste functions in order to reuse parts of formerly defined state charts for example when increasing the number of axes from two to five Restricted changes The state chart diagrams are rather independent from each other also due to the fact that the classes communicate only via signals Most changes have a li
116. bout the edges that link the before mentioned nodes In the class diagrams there are no edges because we did not use inheritance or aggregation The ports are di rectly attached to the class and hence have no connection line and the matching of signals and interfaces to the ports is done by textual data entry In architecture diagrams there are 14 connector lines between the ports 2 8 per view For the state chart diagrams we have 44 diagrams in tree form and 911 nodes altogether A few cycles in the diagrams and a few diagrams with more than one graph keep the balance As a tree has n 1 edges for n nodes we have 911 44 867 edges Visible annotations In the average about 300 characters and in the maxi mum 803 characters are used for the visible annotations per view in our model In the maximum 846 characters are used in our model Invisible annotations Invisible annotations are using about 40 characters in the average per view and 127 characters in the maximum The following table sums up all the figures of this subsection 212 CHAPTER 11 TELELOGIC TAU Diagram Type Diag Nodes Nod Diag Edges Ed Diag Class Diagram 7 36 5 1 0 0 Architecture Diagram 5 37 74 14 2 8 State Chart Diagram 44 911 20 7 867 19 7 All Diagrams 56 984 17 5 881 15 7 11 2 4 Modeling Interaction Supported communication model e Synchronization concerning event scheduling Different types of synchronization mechan
117. ch has to implement the system can not take any advantage by inspecting this code Generated state machines have an ap proximately size of 35kB including header files Additional code of about 85kB was generated The compiled TestHarness dll had finally a size of 110kB Readability As stated earlier it s not possible to judge the readability of the generated target code because there s no support for specific targets and moreover the generated code represents only class skeletons 5 3 5 Incremental Development ARTISAN RT Studio supports an incremental development process as well as round trip engeneering But both approaches come along with incre mentations of the system Therefore reuseability modular design and so forth are important Reuse The most diagrams of the original specification could be reused Certainly the specific diagrams which took care of the seat adjustment had to be refined As far as our experience goes it is possible to reuse 90 of the specifiation Restricted changes The changes could be restricted to a few models so only a small part of the specification had to be reengineered 5 4 CONCLUSION 65 Modular design Due to the UML development process and the object oriented software de velopment a modular design has been found as a matter of course The tool supports UML and therefore the tool helped us building this modular design Restructuring The various diagrams and elements are in
118. ch the system is currently running with a different color So the user can use their own state charts to understand the behavior of their designed model Numeric simulation like graphs or curves are not available in RiMC Target Simulation Support The simulation on the target is also available it is based on generated target code Simulating the system on a target requires that the in and output signals from the model you created are assigned to ports the target has RiMC offers various functions to bind this signals to the ports After fitting the signals the target code can be created and sent to the target GBA is also useable in the target simulation Adequacy Simulating the model is only provided by using panels But this is adequate for testing the model because the simulation with GBA is based on generated code and so except for eventually timing differences the same as using the final code on the target Debugging Features RiMC allows debugging only by using panels and the graphical back animation It s impossible to show values apart from panels create breakpoints or using other debugging features Though we sometimes missed the 9 3 DEVELOPMENT PROCESS 169 option of setting watchers on certain variables to directly trace their values while testing the model The self designed panels and the GBA suited well for testing the model we created in the case study Especially with GBA you can exactly resolve in which state
119. ching is realized by question decision symbols and tasks are described in form of C code in task symbols Native C source code can be added in text diagrams or as notes in state chart diagrams Modeling aspects As all notations have been explained we will discuss which aspects can be modeled using them 206 CHAPTER 11 TELELOGIC TAU Archi Di BM Benutzermana ement m internpo anagem ent funkschluessel startfunkschtug Tuerstatus Ba sitzinternport terentriegeR SE Sitzeinstellung sinternport TS Tuerschliesser Figure 11 6 Architecture Diagram bi begin State M pe sinon Sot HOR SolLW So v Sot Sot S cogi Incoming Signal dus Question Defintions Decision Task Y 5 BLOW STZ gt begin Figure 11 7 Components of a State Chart Diagram First of all the behavior of the system and the interaction with the user are specified by use cases use case diagrams and sequence diagrams Next the basic structure needs to be defined with class diagrams and the object model with architecture diagrams Class diagrams define all the elements needed for the system and mainly contain general ization aggregation and associations between classes whereas the in 11 2 MODELING THE SYSTEM 207 teractions are modeled between instances of classes the parts in the
120. class diagrams static structure Example TSG Class diagram IM lt lt Capsuk gt gt E Tsg lt lt Capsule gt gt BenutzerManagement 51Port S1Protocol Wi S2Port S2Protocol role ban T Wi S3Port SteckerS3Protocol ARS i a CanPort CanProtocol hor wert 3 in tuerschlossR hor wert 4 int Ir amp pn wert 1 int lt lt Capsule gt gt no d wer WERD benutzerManagementR amp h_wert 4 sint batt int 11 amp w_wert_1 int offen int 0 Bow wert 2 int oriegel int 0 Bow _wert_3 int amp ow_wert_4 int tsgAdapterr wert amp s_wert_1 int S1ATPort een B Bos wert 2 int CATPort CATProtoco TEES i Iii timer Timing SIRE DSS UT lt lt Capsule gt gt EX d W log Log Tsg dapter wer int Ev wert 2 int e SiPort SiProtocol egenis n lt lt Capsule gt gt B InCanPort CanProtocol amp omgm leer int i1 StzEinstellung InS2Port SzProtocol amp mgm2Jeer int 1 QutS1ASPort S1ASProtocol amp omgma_leer int 1 CutCASPort CASProtocol omgma leer intel SBPort BSProtocol B QutS24SPort S2ASProtocol S1ASPort S1ASProtocall OutS1ATPort S1ATProtocal I CASPort CASProtocol B OUtCATPort CATProtocol S1APPort S1ABProtoco S2ASPort S2ASProtocoll QutS14BPort SIABProtpcol CABPort CABProtocol WE timer Timing QutCABPort CABProtocol S2AeP
121. commented All identifiers in the generated code directly correspond to the element names in the model e g class names and actor names variable names state names event names protocol names 12 3 5 Incremental Development Reuse It was possible to reuse 90During our modeling phase the specifi cation has changed and some error were not present anymore But we cannot say that the specification is now error free But it was not the goal to provide a bugfree specification We know that in the real world the software architect changes the specification and not the de velopers Restricted changes The most changes were in the part of the seat adjust ment We decided to change the specification to a logic consistent way During the modeling phase we had not enough time to send the changed specification to the software architect All other parts were nearly bugfree expect some small changes we made But the main point is that the hole concept of the architectur was good and therefore we were able to change small things Modular design The tool itself has hirarchically structure and that was the point where we get the idea of structuring our model as we did So the tool helped us in that way to find the right structure Most things are provided by the fact that the tool uses the ROOM language for describing the model and therefore it was logic to use a layer ar chitecture During the work we changed many functionalities of the layers and tha
122. communication Concerning time synchronization it uses a hybrid model Communication is performed in a synchro nized manner all components communicate in a time driven round based scheme with a global time rate for all components Within each round events for occurrence of a message as well as as the non occurrence can be detected Matlab Stateflow Signal based time driven Matlab Simulink use a sig nal based communication Time synchronization usually is performed time driven with individual rates for the components additionally there are some predefined events like function calls or value changes rising falling edges Note that from a formal point of view event driven systems can be transformed into time driven system and vice versa either by adding timing events or by adding explicit absence events however when considering additional restrictions like idle load or efficient simulation those transformations are not always suitable 32 CHAPTER 3 RESULT SUMMARY Rhapsody Signal based time synchronized event driven Rhapsody in MicroC uses signal based communication Concerning time synchro nization it uses an hybrid model Communication is performed in a synchronized manner all components communicate in a time driven round based scheme with a global time rate for all components Dur ing each round boolean events and change events are created in a run to completion form till no more transition can be fired Rose
123. component layout is too small and therefore the pins are positioned one upon the other The error messages could be more significant than they are The mod ular design of ASCET SD is restricted that way it allows to connect messages only if they have the same name Hence you have always to be careful that messages are called equally Another thing to im prove is the stability of the system It brings system errors during the work process and recommends to restart the program Sometimes it crashes without any warning message Helpful properties Very helpful for our case study was the extensive mod elling language that allowed flexible specification All components 6 5 MODEL OF THE CONTROLLER 91 could be tested quickly in the Offline Experiment There the various displays and the possibility to configure the parameters during the simulation helped to find errors easily Missed ASCET SD offers the possibility to specify protocols but we have not found any guideline to use this feature Even in the manual there is no comment We suppose that such a protocol would have been more adapted for modelling our CAN connection Furthermore we missed that ASCET SD offers no version manage ment tool The concept of semaphores is missing It would have been very help ful to control the access to variables messages and especially for our case study to make sure that at most two seat axes are adjusted The last missed feature is a sort of a slow
124. cordingly this report is not meant to be a recommendation to select a development tool for a specific application domain Furthermore since those tools do target different development phases different application domains as well as different development techniques it is paramount to select the tool that fits best into the desired development process Thus while the following overview can help to get a first impression of the rel evant aspects of a tool as well as the state of the art in CASE tool support this study cannot replace a profound tool selection depending on a thor ough definition of the requirements of the tool users 13 What This Report Does Aim At The case study shows what modeling concepts are reasonable and can be useful in the domain of embedded systems It also shows that general pur pose object oriented modeling is not desirable in this domain suitable tools have to address issues like e describing structures more abstractly than on the level of class object diagrams e introducing communication mechanisms more suitable than method or procedure calls e modeling reactive behavior as well as data flow Furthermore we show what models and description techniques are com monly accepted as essential giving a state of the art snapshot of the CASE based specification of embedded software Additionally we show what kind of tool support is available for the development of such specifications and what the resulting deve
125. d The behavior of the single classes and the interaction of their instances make up the biggest part of the system as it contains all the logic that is needed to fulfill the specified behavior of the system The system it self consist of three classes Benutzermanagement Sitzeinstellung and Tuersteuerung The interaction between the different parts is modelled in architecture diagrams We have different architecture di agrams for the communication betwenn the parts of the system and for the communication between each part of the system and its envi ronment The behaviour of the classes is described in state chart di agrams Most of the classes have more than one state chart diagram Each state chart diagram describes the behaviour of its class when it is in a certain state and receives a special signal For example if the 11 2 MODELING THE SYSTEM 209 Benutzermanagement receives the signal that the MGMT1 Button has been pressed it tests the batterie and if there is enough voltage it sends a signal to the Sitzeinstellung to handle the move of the seat otherwise it sends the warning B LOW SITZ Notations suitable The modeling with architecture diagrams caused some trouble because this notation is new in UML2 and therefore neither official nor commercial documentation or literature was available in winter 2002 2003 For example it is not obvious why you have to define transition lines connectors between two ports of differ
126. d including why they were not used a possible reason is of course that these feature were not needed in the case study especially in the target platform section Finally the support for incremental development is addressed 2 3 DEVELOPMENT PROCESS 19 2 3 1 Applied Process This subsection gives a short summary of the development as performed in the case study For example it is described the development process is started defining system boundries describing initial use cases how model of the system is obtained refining use cases by sequence diagrams defining data structures as well as which further steps were applied sim ulation checks test etc 2 3 2 Applied Process Support Here all aspects that aid during the development process are listed espe cially addressing the question how much a tool has helped to understand the specification and whether the tool supports to get models with differ ent degrees of detail starting with a coarse model doing early simulations etc Simple development operations Does the tool provide simple develop ment operations e g cut and paste of parts of a diagram If yes which operations are supported Complex development operations Does the tool provide complex devel opment operations e g calculation of scheduling protocol integra tion partitioning on hardware components If yes which operations are supported Reverse engineering Is reverse engineering supported b
127. d ensures the hierarchy of the designed model A 9 4 CONCLUSION 171 database with all files including their history assists the user by realizing his concept Nevertheless the database requires a very structured handling by the user because different updated versions combinated with some old versions of files used in a model can create difficulties with the following and sometimes enduring debugging RiMC offers a very nice approach in modelling the design of a system The user can create diagrams which are very similar to the UML diagrams such as use case or sequence diagrams and therefore he has manifold methods for approaching his assignment There are possibilities to build sequence diagrams which can be reused to check whether the specification is satisfied and a correct behavior of the model is guaranteed The func tionality can be designed by state or flowcharts The functions are realized with propositional logic including conditions or events The transitions in the statechart can be labelled by these functions or can be defined by static reactions in the states itself Unfortunately the clearness of the model is reduced with increasing complexity of a statechart Furthermore the user has to care by himself for the layout of his created statecharts which can be work Besides the user has to deal with an open window for each file which should be changed and many different scrollbars options and tab ulars need time to get an overview B
128. d such a library after completing a project This way all the universal components can be easily reused in later projects Development history No development history is supported Buta backup can manually be made by exporting the project This is very impor tant because AUTOFOCUS tends to crash once in a while Unfor tunately it doesn t have an undo function This can be very critical when a whole component was deleted unintentionally 73 3 Applied Quality Management Host Simulation Support Yes we were able to run the simulation on the workstation No expensive test hardware was necessary The simula tion was run using the AUTOFOCUS GUI It is also possible to gener ate test drivers and to run the tests on the generated c code Here it is useful to reuse the test vectors saved in graphical simulation This makes testing easier Target Simulation Support A driver for the c code could have been gen erated to test the program on the target hardware 7 3 DEVELOPMENT PROCESS 111 Adequacy We used the graphical simulation a lot This way we were able to view the SSDs and the STDs and to track the signals graphically In the environment window we were able to enter the input signals It was easily possible to reenter the same signal a few times Unfortunately no history of the signals before is kept That s why one has to always retype the whole input signal if it wasn t the last one Also the size of the textfield is too
129. d their respective diagrams and sequence diagrams Both were not used because they are suitable mainly in the analysis phase of software engineering that was not necessary because of the require ments specification we have already been given But we used the possibility of the model verifier to automatically create sequence di agrams out of the model and we compared those diagrams with the specification we had Another point is that we modeled all state chart as transition oriented states and actions are modeled as nodes and not as state oriented only states are nodes Those two types are iden 210 CHAPTER 11 TELELOGIC TAU tical regarding the source code produced but the former one is more readable Missing notations In general there was no notation we really missed Two things that could be improved in the future regard to use case descrip tion on the one hand and modeling with superstates on the other hand The use case is only described textually We could imagine using a predefined form with references to actors and other use cases and linking to the other kind of diagrams For extensive requirements analysis Telelogic offers a separately available tool called DOORS which can be fully integrated into Tau Another useful thing might be superstates hence enabling hierarchi cally organized state charts As far as we know it is planned to inte grate superstates into Tau but it must be mentioned that superstates also lead to some
130. del the entire environment for testing and simulation purposes Figure 12 1 shows the structure of our model with its actor sub components The main functionalities have been marked Geschwindigkeit a_Geschwindigkei SitzsteuerungLinks BMGMT a Sitzsteuerung a_BMGMT Tuere Links ANBA 3 Tuere L IT Wr Col a TuerMoto sim or Rechts a TuertMotor TSG Tuer Rechts a TSG nachbar Figure 12 1 TSG System Structure 12 5 MODEL OF THE CONTROLLER 239 Each actor was modelled in the same way starting with modelling the structure of the actor or group of actors in the structure editor and contin uing with the definition of the behaviour in the hierarchical state machine editor The structure view editor defines the interfaces of the actor with its envi ronment the ports and other actor components contained in it if applicable as not all the actors do have subactors EN Actor AM Sub components Figure 12 2 Structure of actor class a Tuere The behaviour the Service Access Points SAP additional code of an actor are defined in the hierarchical state machines editor Figure 12 3 is an example for the behaviour view of the left door actor This state machine has three states Tuere offen door open Tuere geschlossen door closed and Aktion action Depending from the input messages the door is open closed or it is changing from open to closed and vice versa The state Aktion Action
131. description techniques were intensively applied which are more or less directly integrated in the development process see also 3 3 either because a simulatable specification or code can be gen erated from them like from structural behavioral or data descriptions or because they are generated from other descriptions like interaction de scriptions To a limited degree other description techniques are used to get a first impression when analyzing the system like interaction descrip tions and Use Cases Since those description techniques are only weakly integrated in the development process e g no other descriptions can be generated from them or checked against them they are only used spar ingly 3 2 MODELING THE SYSTEM 29 Finally the case studies are focusing on modeling the system rather then implementing it Therefore the above mentioned aspects of defin ing task and schedules as well as organizing the system in packages were kept to a minimum accordingly corresponding description techniques are hardly used In general the tools focus on the four common description techniques to specify and validate the system under development Accordingly in the case studies mainly those description techniques were applied to de scribe structure and interfaces behavior interaction data Additionally were available use cases were used in an early stage to structure the func tionality and to collect interface information Si
132. dn t have to make big changes regarding the specification 7 4 MODEL OF THE CONTROLLER 113 canMsgIn CanMsgInDTD canError ErrorDTD gt sanvindewContrelWindewoonlrelDTD canTurnSignal TurnSignalDTD canUserManagement UserM anagermenDTD canCentralLock CentrallockDTD plug Msgin Pjug1 MsgInDTI plug2M sgin Pjug2M sgInDTI plugiMsgOutiPlug1 MsgOut plug2M sgOutPlug2M sgOut DTD DTD Figure 7 1 The main components Modular design With the AUTOFOCUS tool we were able to build a modul based TSG The main component consisted of tree parts The User Seat and Door Control The AUTOFOCUS tool works best when a top down approach is used Starting out building Subcomponents and putting them together afterwards may turn out to be quiet difficult Restructuring After exporting the project in the QML format it can be used to create a user defined library Using this library restructuring and refactoring can be done 7 4 Model of the Controller At the beginning we separated the whole system into four components Plug 1 Plug 2 CAN and TSG door controller Plug 1 Plug 2 and CAN were build in order to deliver messages to the TSG and to receive mes sages from it According to the given case study we then generated data definitions DTDs Fig 7 4 which represented all those messages For ex ample we designed a user defined type called P1MsgOut containing all single messages which Plug 2 could send
133. document the model That can be done either by insertion of description boxes near the various components or by launching the automatic docu ment generator The resulting document can be a HTML PS ASCII or RTF file and contains all relevant information like names and types of inputs and outputs as well as screenshots and descriptions of the components Development phases The tool can be used during the development phases modelling implementation and test On the other hand the phases re quirement analysis and maintenance are not supported see Fig 6 1 on page 74 Therefore the tool is mainly applicable to model and im plement a given specification test the result and load the generated code on the target platform to make the system ready for use The analysis phase s processes like create use cases class or sequence diagrams have to be done with other tools or by hand For the main tenance process any technical assistance is missing too implementation E Not supported 3 supported Figure 6 1 Supported phases of the V model Documentation Documentation of the tool can be found in the manual and online on the Etas homepage www etas de The manual is delivered with the tool itself as PDF file It is very ex tensive 1160 pages and contains useful information about the tool 6 2 MODELLING THE SYSTEM 75 functionalities and their use Furthermore a tutorial with some exam ples and the description of the compo
134. e the tool chain depends heavily on those forward and backward integrations and a common model bridging the tool chain Since those steps are limited by the information ex plicitly represented in model of each tool of the chain the degree of coupling is limited by the quality of those models and their interde pendence If e g the bus signal communicated on the implementa tion level cannot be related back to messages communicated between abstract components counter examples cannot be expressed on that abstract level The construction of reliable embedded software is of course possible with out a model based development process However research results sug gest that such a process can contribute essentially to increase the quality of the developed product as well as to an increased efficiency of the develop ment itself e Jon91 shows that more than 50 of serious errors are made during design 25 during implementation about 30 of medium errors are made during design 30 during implementation e Jon91 shows that analytical techniques performed on early phase description of the product e g structured approaches design re views require generally at least less than 50 of the effort in both error detection and correction needed for later phase techniques e g integration test field test e Jon91 shows that those analytical techniques of the early phases are at least twice as effective to detect errors of the ea
135. e automata can continue exactly at the state it was interrupted Other describing techniques But state charts and flow charts are not the only way of describing behavior Rhapsody places at the dis posal truth tables and mini specs and subroutines By the use of truth tables functionality can be represent in tabular form Inputs outputs and also actions can be defined Mini specs are specifications in written form and can be placed into activities Furthermore subroutines are available which can be implemented in Ansi C action language or as lookup tables In the panel editor interactions can be modelled using panels includ ing buttons slider text fields and self designed in output devices These graphical objects are connected to elements of the model e g variables of a chart Thus the developer is able to simulate test cases without any target by using self designed panels It can also be de bugged by comparing input and output values Rhapsody offers the possibility to generate such a Panel automatically by the panel builder Modelling aspects Activity charts picture the structure of the project while flow charts and state charts represent behavior To show interaction sequence diagrams and usecase diagrams can be used Type of notation The following notations are supported Tabular nota tions in the form of truthtables textual like reactions or labels on tran sitions and graphical notation i e the different kinds of c
136. e by dividing the problem into three parts The User Seat and Door Control This was the division shown in the specification Each of those parts was modeled as a blackbox with interfaces to the outside Fortunately not too much inter action between these components was necessary Every team member was delegated one of the components This way it was possible to work parallel on the system First the structure in the Component was designed Then a automaton had to be build for every sub component which wasn t further divided Sometimes it was possible to reuse an existing automaton Then every Component was tested in standalone behaviour After all these tests had been successfull we could start testing the whole system 7 3 2 Applied Process Support Simple development operations It is possible to copy SSDs and to reuse them again It is also possible to build your own SSD library This is usefull when you have SSDs that you use frequently in different projects There is also an existing library with basic components We didn t use this feature because there were no suitable components for our task It is also possible to reuse existing STDs This is very use full The STDs are linked to the SSDs By this concept a STD can be connected to multiple SSDs Very usefull is the copy paste functional ity in Transitions It saves quiet some time to copy an old Transitions and to make some changes instead of building it new Complex development
137. e components send or receive Use Case diagrams Use Case diagrams serve as well for picture the interaction of user and system as for structure of single use cases They define also the interfaces of use cases An Example of an use case diagram is shown in Fig 9 1 In the use case diagram you have an actor icon that is a symbol for the user this icon is bound to his use cases by lines This use cases again are split into different uses cases The connection between this use cases is symbolized by arrows Flow charts Flow charts are charts without states always running from start to end For an example flow chart see Fig 9 5 The flow chart diagrams have rhombus for conditions and rectangles for actions They also consists start and end points and the flow is always from start to an end point 160 CHAPTER 9 RHAPSODY IN MICROC yes CURR_CNT CURR_CNT 1 h CURR_CHT 20 Figure 9 5 Example flow chart Activity charts Activity charts which illustrate the structure of the project are made up of the following objects Activities to represent the various functions external activities to picture the environment control activities to display the behavior of the activity and flow lines to represent the information flow The flow lines can be container of the most different types of variables as there are integer and real bits and bit arrays and also higher data types like records unions and user defined da
138. e parts of the model to simplify the detection of errors It is also possible to sim ulate code which was compiled for an embedded application and is runnable on a platform different from the development system with Real Time Workshop Embedded Coder This functionality is called software in the loop or processor in the loop With Real Time Workshop s Rapid Simulation Target one can generate code from models which can be run without using the Simulink solver and thus be transferred to hosts without a MATLAB installation Target Simulation Support Stateflow and Simulink offer the possibility to simulate the created code on the target Therefore the RealTime Work shop includes special functions to connect the target with the host e g via TCP IP You can then transfer the code to the target run it there 8 3 DEVELOPMENT PROCESS 133 and view the simulated system on the development host e g with animation of the chart Adequacy As all of the simulation results are data in your Simulink model you can adjust the presentation of the output in different ways e send it back to the MATLAB workspace e save it into a file e post process it with the help of another Stateflow chart or a model in Simulink for example you could display the results in a spe cial Simulink block called scope We appreciated the various possibilities to handle the simulation re sults Debugging Features As Simulink simulates a model by executing g
139. e so called mod els neighborhood or the copy paste operation between different diagrams Besides the team wants to point out some minor aspects e The user only has weak control over the presentation of model ele ments e g shadows line thickness e some graphical elements cannot be resized and e after copy paste operations all objects interface devices classes etc are arranged one upon the other 5 2 Modeling the system This section describes how ARTiSAN RT Studio supports modeling a sys tem and which features were used to model the case study 5 2 1 Available Description Techniques ARTISAN RT Studio offers several diagram types Each diagram type can be used to express different views on the model This section describes which diagrams are offered what they can be used for and which graphical elements provide their functionality Supported notations The different diagram types supported by ARTiSAN RT STUDIO are listed here According to figure 5 1 they are grouped by the scope and the model they get used CHAPTER 5 TOOL ARTISAN REALTIME STUDIO 54 Figure 5 1 Models supported by ARTiSAN RT Studio K e1nj2e3lu24 v FO 5 4 k 22U SlSl d 4 IPPON SWIEIJBUON pon ulajs c wajsig iR Adua1INSUOD I 2 lapo lapoj uon2e49ju 5 2 MODELING THE SYSTEM 55 Scope Model Diagram types Requirements System Scope Model System Architecture
140. e that a series doesn t move an axis if it already has been moved by the other series the two sides are synchronized by the use of semaphores When all the opening movements of the axes are com pleted the next state chart is entered This chart is similar to the described one with the only difference that it performs the closing movements of the axes When the requested seat position is reached the automata returns to the idle state The third possible user command is the adjustment of the seat position triggered by one of the two wireless keys In this case the required val ues for the axes are loaded into variables which are shared by the chart SITZSTEUERUNG and an interrupt signal is set which triggers the SITZS TEUERUNG to move all the axes simultaneously Component SITZSTEUERUNG This component triggers the five axes in order to control the seat position and regulates the manual adjustment by the user Movement of the axes is either triggered by the chart BENUTZERMAN 9 5 MODEL OF THE CONTROLLER 175 DEFFNENDE_BEWEGUNGEN H E E PETERE OP_TEST2 ot LSEMA HOR1 ot CSEMA_WI tr SBMA_W 5 OP_HOR gt E HSE HOR enTe na eo d not LSEMA Mer nis HOR_START_CL J tr SEMA_W 5 ACHSE_HOR_CH R and tsEMA WI and not CS s BMMG H R_START A ws SEMA and not TS r z pHMG n ch bn and T SERA ist A pos Eaonse SENT pr pe Esem_ Hirn Po not TSEMA art Meme STAR DEN ta SE por nd
141. eal time Studio Tutorial Part 1 Formerly deleted elements can be restored at a later time Complex development operations Complex development operations like protocol integration or partitioning on hardware components are not supported directly by RT Studio In turn these informations can only be added as hints for the developers 62 CHAPTER 5 TOOL ARTISAN REALTIME STUDIO Reverse engineering The reverse engineering feature is available for C C Java and Ada User support A lot of design guidelines in the RtP mentor helps the user during the whole development process There are wizards available for every tool of RT Studio e g for the state machine generator Consistency ensurance mechanisms The consistency is assured by the underlying database and the sophisti cated connections between the various diagrams objects elements Be yond that there s a consistency check available which recognizes apparent design failures The syntax is kept consistent but semantical checks are not possible For example wrong parameter passing within sequence diagrams can lead to wrong models but are not reported Component library There s no component library available for ARTiSAN RT Studio Development history There s the opportunity to create different versions of a model manually in the ARTiSAN Models Neighborhood but an automatic versioning sys tem is absent But if needed third party CM tools can be used for gaining
142. eat staying in its boundaries Connector Classes Through the connector classes all events mentioned in the case study can be sent and received On the one hand these classes observe the connectors for incoming signals and forward them to the model layer On the other hand they offer a set of constants to the model layer to send the different signals 5 5 MODEL OF THE CONTROLLER Figure 5 5 One exemplary class per layer of the Class Diagram Control Layer Model Layer Physical Layer 71 CHAPTER 5 TOOL ARTISAN REALTIME STUDIO 72 Figure 5 6 Example of the Statechart Diagram of a Connector Class Ias Ls ML Qaeda Dans 3a 101380002 una R3420751 j 318319 gt l Ope UO AZ L TLO W HLNIZ PUGS L10728u002 490131 400q IO AZ b Qo Az LE fpesoonqes GIG AZ L LOW SLNAZ pues 107280005 3sje p8y 901 OW HIN3Zpues 10j28uun LOW HIN32puas 10 3auun 0 SHOWA SINS L019u002 puas 101380402 Ee ENS LI 29 uu02 puas 10380002 i Ean pa 4301 i388 L 3 WILL 084907514000 Chapter 6 Ascet SD Josef Maran Martin M ssmer J rgen Steurer 6 1 General Aspects In this section we provide general information about the tool Functionalities ASCET SD offers an extensive set of functionalities to fa cilitate modelling and implementation of a given system specifica tion It provides its own modelling language that consists of sev era
143. ed to describe the task structure of the system and the schedules of activation e g ASCET SD Artisan Additional Analysis Descriptions like UML Use Cases Process or Activ ity Diagrams e g used to describe the functional structure or the technical process controlled by the system Artisan Rhapsody in Mi croC Rational Rose RT Implementation Organization Package Deployment or Component Di agrams used to describe the code package structure e g Artisan Rational Rose RT Mapping Descriptions used to described the map ping between interface elements and memory areas e g ASCET SD Artisan To structure the specifications throughout the tools each graphical de scription technique supports hierarchical structuring e g component sub components state sub states 3 2 2 Applied Description Techniques As mentioned above most tools focus on a small set of description tech niques covering structure behavior interaction and data UML driven approaches e g Artisan Rose RT add additional description techniques some complementary e g Use Case Diagrams some focusing on im plementational aspects e g Package Diagrams or Component Diagrams others describing similar or overlapping aspects e g Collaboration Dia grams and Sequence Diagrams Since in those approaches not always all notations are applied this section focuses on the description techniques applied in the case study In general only those
144. elopment process was separated into two expansion stages In the first one only two of the five axes of the seat were realized This require ment was given because one goal of the case study was the approach to incremental development by the different tools Going to the second step in which all five axes had to be realized all charts which are involved in controlling the seat had to be completely renewed only the door latch that is separated from the two steps could be reused Besides minor adjust ments of the system interface the main activity chart was not affected by these changes First of all in the modelling process we started creating a use case and various sequence diagrams These diagrams were usable in both steps The use case diagram gives a overview over the system boundaries like the user interface and the several functions that had to be realized After we determined the system boundaries we began creating the model Generally it is structured in three parts the door latch the user manage ment and the seat control unit We started designing different activity charts one for each of the three components and a main activity chart in which the three parts are encapsulated and which defines the interfaces be tween these three parts and the interface to the environment of the system like the sensors the motors and the can bus Afterwards we realized the behavior of the three components in state charts one or more state chart for e
145. ementation code to the capsule state diagrams In addition we have used sequence diagrams to capture the intended behavior of the system for various use cases We have used Rose RealTime s execution and debugging tools a simulation environment to validate the model behavior at run time Once the design has stabilized we have used state diagrams for capsules and protocols to capture the ab stract design This is particularly important for protocols where the state machine specifies how a capsule using that protocol must behave Simple development operations Rational Rose Realtime provides simple development operations such as cut paste copy delete of parts of diagram and so on Complex development operations Rational provide complex develepoment operations like calculation of scheduling We did not use this feature for modelling the TSG of the case study Capsules can belong to dif ferent logical threads Each thread can be assigned a separate priority so that the designer has some control over the scheduling operation Reverse engineering Rational Rose RealTime works with your existing code we did not use this feature for modelling the TSG of the case study You can reverse engineer your existing code into UML and work with it in Rational Rose RealTime and you can manage your existing code using your existing tools and processes and have your Rational Rose RealTime application compile and link against that ex ternal code
146. en is re ceived the state variable key_abschliessen Boolean is set to true This makes it easier to check whether the conditions are fulfilled The WillVerriegeln and WillEntriegeln state machines have similar be State variable set to true 4T Figure 12 5 Illustration of State machine TOP haviour Both contain three states CheckVorraussetzungen Verriegeln or Entriegeln and Fehler Error The first two are sub state machines and the last is just a state for error handling We did not specify any further action but it can easily be done by simply adding a sub state machine The aim of the state inf Figure 12 6 is to check all the conditions needed Checkvorraussetzungen to start the un locking action respectively If all conditions are correct the un locking process starts in the next state If not the state Error is entered In the next state Check Vorraussetzungen we implemented how all the conditions are checked and depending on the result actions are taken on a hierarchy higher un lock or error states Basically this is how Trice works and the model looks like The other main functions of our TSG were modelled similarly Their responsibilities are described below The functionalities of the modules are the following 12 5 MODEL OF THE CONTROLLER 243 Figure 12 6 Sub State Machine TOP WillVerriegeln 244 CHAPTER 12 TRICE TOOL BY PROTOS SOFTWARE GMBH Nom Check Voraussetzungen cire TL COM O
147. en we show how the architecture of the model is built up by these components Finally an example will illustrate how the components state charts send and receive signals 11 5 1 Packages and Classes The whole model consists of three packages In the main package there is one top level main class having three classes which describe the essential part of the system The main class contains all class and architecture diagrams of the core system Each class contains its own state chart diagrams that describe its behavior The class diagram CD TSG see Figure 11 14 contains the three core classes Benutzermangage ment which manages the interaction with the user Tuerschliesser which contains information about and routines for opening and closing the door and Sitzeinstellung which has mechanisms for coordinating the move ments of the seat with semaphores The signals and interfaces are defined in a separate package We or ganized them in five class diagrams three class diagrams for the inter faces and signals used in the three classes Benutzermangagement Tuer schliesser and Sitzeinstellung one diagram for the signals received by the the sensors and one for the signals needed for the internal communi cation All signal were already specified by the case study except for the internal communication which can be seen in figure 11 15 222 CHAPTER 11 TELELOGIC TAU CD TSG active class main 1 12 DR
148. ends the in formation through a merger to Seat Control For that action we defined a special data type which contains the seat position value and also the infor mation if the key or a user button ordered it 7 4 4 Merger The Merger component collects all messages from the other components As nearly no component uses all values offered by a CAN data type or plug data type the Merger receives the relevant values and composes them to messages which are flushed to the CAN Bus or the plugs 7 5 Conclusion 7 5 1 Benefits First of all one strength of AUTOFOCUS is the possibility to design systems graphically This feature makes it much easier to understand the depen dencies of the components and to follow the message flow between them Developers can easy implement functionality by visualizing it One more benefit is the project architecture of AUTOFOCUS which is char acterized through the offered modular design The system can be divided into subsystems which can again be divided and so on The divide amp con quer strategy can be applied In addition the concept of Data Type Defini tions DTD makes it easy to handle communication between the entities Another important feature appeared when we tested our model The graph ical simulation helped us to find out errors and inconsistencies in our sys tem design In the single step mode we could follow the messages running through the channels and watch the changes in the variables of our c
149. ener ated code only debugging on code level is possible The available debugging features can be found in two places in the dialogue for the simulation parameters and in the debug dialog The simulation parameters dialogue provides sophisticated control options to configure the diagnostic features according to the user s demand For example one can adjust settings for the solver the sam ple time data checking type conversions block connectivity or back ward compatibility The debug dialogue in Stateflow provides the user with the following features e setting breakpoints Breakpoints can be set for the following events chart entry state entry event broadcast and state entry e step by step execution After a stop the simulation can either be continued normally or you can step through it one by one to watch control flow more exactly e injection of events e run time display of variables If the simulation is stopped one can browse through data and active states Additionally the call stack is available for evaluation e error checking One can enable these four error checking op tions state inconsistency transition conflict data ranges detect cycles Another useful tool is that the simulated model can be animated dur ing the simulation By this one can track the control flow and find semantic errors of the model 134 CHAPTER 8 MATLAB STATEFLOW Testing Simulink can read in test data in array or matrix from a f
150. ength between them Afterwards the transition to zu is taken and z a start becomes the active state 8 5 MODEL OF THE CONTROLLER 141 a z strom can send zv schl J tjcan send win v ol zy can send win vr cg motor zentralverriegelung ZU hime in TIME us of in T RIEGEL 0 Gin_TIME time lt 3 Ox n_TIME time gt 2 evi_TIME Os Ox Ox x can send error key 1 in T RIEGEL 1 motor mh en E evt TIME Kl Q in_TIME time lt 4 n in ERROR KEY 0 Cp e ei in ERROR KEY 1 Figure 8 8 Statea z strom Seat Adjustment The second main component can be divided into two parts first the man ual seat adjustment and second the seat adjustment of the user manage ment Manual Seat Adjustment The model for the manual seat adjustment con sists of five parallel states one for each possible direction of seat ad justment and the supporting graphical functions These five possi bilities of adjustment are e the angle of the back e the distance steering wheel seat e the width of the seat and e the height of the seat front and back Exemplarily the process flow of adjusting the position of the seat will be explained through the state sitz vorne the four other states are similar in their structure In the beginning the model is in the state idle v and checks first whether the according button is pressed This is performed by the function sitztaste sitz
151. ent ob jects if on the other hand event based modeling normally does not require that And in fact when testing our model we discovered that a part A which is not connected to a part B but has the same interface as a part C which has a channel to B could receive a signal that is supposed to be sent from B to C At the beginning we also faced difficulties using the state chart dia grams This type of notation combines constructs of UML1 and SDL two modeling languages of rather different domains and it is not al ways evident which concept was taken from which language Besides from that the tool fully enables modeling all aspects of the case study within the whole software process And even more the tool contains an integrated verification simulation and testing sys tem Clearness As mentioned in the item Hierarchy of the last section the tool provides some very useful constructs for organizing and struc turing the model in an hierarchical way By drawing the diagrams and adding new graphical nodes or variables the regarding elements are created automatically in the appropriate position of the tree model You need to be careful to break down the system into components of adequate size in order not to get too many elements per component but this is a problem of software engineering that software tools can not solve at least not at the moment Unused notations There were two kinds of notations that we did not use use cases an
152. entation including code generation Furthermore some of the tools also support the later steps of requirements analysis e g by offering UML features like use cases and sequence dia grams or supporting a link to requirement management tools like DOORS While generally there is a tight integration between the design and the implementation step e g by customizing code generation for specific sys tem and hardware platforms other phases of the development process are less tightly integrated For example the generation of test cases out of re quirements specifications like sequence diagrams is somewhat weak e g transforming abstract messages in bus level signals such that these fea tures are only of limited use Similarly supporting a connection to the DOORS tools offers only little integration of the informal requirements analysis for a tighter integration features are necessary like tracing the requirements to the code level or obtaining coverage measurements con cerning the defined test cases Toward the later phases especially validation and testing there usu ally is a tighter integration Generally the tools offer some form of a sim ulation feature to validate the design some support test driver generators setting up a test bed and translating e g low level sequences into test cases Again more elaborate forms of support could ensure a more systematic test process e g generating input sequences to reach specific states e
153. er in the best case Rhapsody in MicroC builds the code automatically from the model Testing is done by the use of graphical panels as mentioned above In the deployment phase Rhapsody in MicroC allows to integrate tar get cross compilers into the automatic code generation process For many target micro controller compilers preconfigurations are avail able Nevertheless by writing own configuration scripts it is possible to integrate not supported target compiles Documentation Rhapsody in MicroC ships with a bunch of help files in portable document format PDF which cover installation instructions quick references to the product and tutorials Furthermore a variety of user guides are provided e g a Programming Style Guide and style guides on the different kinds of charts Although the index page of the documentation didn t work in our re lease the PDFs are helpful for a quick entry into Rhapsody in MicroC as well as for further information such as whitepapers guide lines etc Furthermore the context help system in the application itself is very useful when the developer is not sure about a certain detail of the 158 CHAPTER 9 RHAPSODY IN MICROC y Rhapsody in MicroC 3 1 Project FINAL E jol x File View Options Utilities Help gp Horkarea Databank owser Brouser Editors tor 7 P WER iud w A DataDict GBA Check Hicro C Docunent Brouser Server Hodel Code Generation Generator Rhapsody in MicroC
154. ere s no direct support for these activities During every phase of the development process the model can be au tomatically verified With the Report Consistency function leaks within the model can be discovered Even though the models are implicetely con sistent because of the underlying database apparent design failures are reported Unfortunately not all information of the model is used for this For example wrong parameter passing between objects in a sequence dia gramm is not recognized 5 1 2 Development phases ARTISAN RT Studio assists the developer during the two phases require ments analysis and design modeling The implementation activity is con fined to code generation class skeletons and the synchronization function ality between code and model Test and deployment is not supported All development phases are vividly described in the so called RtP mentor see 5 1 5 1 3 Documentation There s no print version of the manual available The online help is very good not only because of the clearly arranged information and graphical 5 2 MODELING THE SYSTEM 53 representation in the RtP mentor but also the extensive information behind the scope of the provided functionality is very useful 5 1 4 Usability All in all the usability of ARTISAN RT Studio is good The handling is very intuitive The main issue the authors have to mention are the long waiting periods e g during the import export of models in th
155. ered Views 40 views structure diagrams and state machines are used in the whole model Nodes 70 nodes capsules and states are used in the whole model In average four nodes are used per view and maximum ten Edges About 212 edges connectors and transitions are used in the whole model In average eight edges are used per view and maximum 20 edges 10 2 MODELING THE SYSTEM 189 Visible annotations Maximum 1500 characters transition label and con nector name are used for the visible annotations per view Invisible annotations Maximum 1000 characters trigger guards are used for the invisible annotations per view 10 2 4 Modeling Interaction Supported communication model the following communication models are supported by the tool e Message synchronous handshake blocking synchron If syn chronous communication is desired a blocking send can be used During the invocation of the method the sender invoker is blocked until a reply is received even if higher priority messages arrive At the other end the receiver does not normally distin guish between synchronous and asynchronous communications but replies to either in the same way In this way the receiver is decoupled from the implementation decisions of its clients re garding which communication mode to use that is blocking or non blocking e Non blocking usually buffered asynchronous If an asynchronous send is used the sending capsule will n
156. erten Werte angesto en Finden sich unter den jeweiligen Speicherposition keine Einstellung so entf llt das Ansteuern des Sitzes Speichern einer Einstellung ber CAN Empf ngt ein TSG die Botschaft M SAVE 1 M SAVE 2 M SAVE 3 oder M SAVE 4 so speichert das TSG die Werte der Sitzeinstellung in der entsprechenden Speicherposition Initialisierung Keine Aktion 5 4 TurschloB Eing nge e Zustand Vordert r und T rschlo SI KEY STATE S1 T_RIEGEL SI T OFFEN 20 e SchlieBbefehle ber CAN CAN ZV_SCHL_A CAN ZV_SCHL_L e Z ndung CAN KL ISSTART e Motor lauft CAN MOTOR LFT e Batteriespannung CAN BATT Ausg nge e SchlieBmotoren SI ZENTR MOTI ZENTR MOT2 e SchlieBbefehle ber CAN CAN ZV SCHL R e Ansteuerung Fahrzeugblinker CAN BLINK CAN DURATION e Fehlermeldungen CAN ERROR KEY CAN B LOW KEY Verhalten Generell Die Funktion soll dem Prinzip folgen da entweder alle Fahrzeugt ren verriegelt oder alle Fahrzeugt ren entriegelt sind Wird eine einzelne T r ver bzw entriegelt so m ssen alle anderen T ren diesem Vorbild folgen Im Zweifelsfalle hat Entriegeln Vorrang vor Verriegeln z B wenn ein Fahrgast die T r von innen ffnet entriegeln w hrend der Fahrer die T ren mittels Funksender verriegeln m chte Solange wenigstens eine Fahrzeugt r offen ist kann das Fahrzeug nicht verriegelt werden Aufschlie en des Fahrzeugs Die Fahrzeugt ren werden entriegelt
157. es e some form of analysis to detect inconsistencies 23 24 CHAPTER 3 RESULT SUMMARY e the possibility to simulate the design software e the generation of code or code fragments from the design and e the generation of documentation On a closer look however the tools differ noticeably concerning supported description techniques support for developing and analyzing the design the support for generating deployable code or generated documentation Roughly the used description techniques can be divided into two classes one supporting large parts of UML the other mainly centered around the real time subset block diagrams and state transition diagrams Section 3 2 treats this in more detail Due to the complexity of the complete development process the inves tigated tools obviously cannot cover the complete development process Therefore an important aspect of the tools is their integration in the devel opment in terms of interfaces to other development tools e g tools for requirements elicitation and analysis configuration management or re gression test While some tools offered only support to import and ex port models others have support for a client server architecture to support shared development with other users and tools or support integration into version control systems A reasonable comparison of the generated code is not possible because the models have different functionality the generated code includ
158. es and after this was successful we extended our model to all five axes of adjustment After finishing the manual seat ad justment we were able to reuse a lot of components for the implementation of the user management As the user management has two ways to invoke an adjustment procedure we split the development we started by realizing the less complex case i e the trigger via CAN bus After this we built the part for the user management button in analogy with the extension to two phases of adjustment and the constraint to two motors at one time Finally we realized the memory management unit After having realized all of the specified functionality we began with testing our models Therefore we first described use cases that covered nearly all requirements of the case study We wrote the input data in an Excel sheet fed it into our model with Simulink s From Workspace block and started the simulation The resulting output data was written back into a MATLAB matrix from where we copied it into our sheet and compared it to our previously defined reference values There is also the possibilty to build a GUI for tests with the help of MATLAB s GUIDE a GUI editor that can interface Simulink models During our development process the tool supported us mainly with its capability to reuse and adjust existing components in an easy way Exten sion of the model can be achieved without problems too The tool did not help us with the analysis
159. es or ex cludes support for the graphical simulation and the code has been gener ated for different targets To give a impression of the size of the system however the different sizes are listed e Artisan 110 KB PC e ASCET SD 584 KB PC including simulation e AutoFOCUS 31 KB PC e Matlab StateFlow no code generated e Rhapsody in MicroC 7 KB Target e Rational Rose Realtime 757 KB PC including simulation e Telelogic Tau 81 KB PC e Trice 30 KB Target A further rather distinctive feature is the support of consistency analy sis Section 3 3 2 gives a more detailed analysis However often this form of analysis is not sufficiently integrated into the modeling phase and still to limited with respect to a real model based development process 3 1 GENERAL ASPECTS 25 All tools have support for the generation of documentation e g gener ating a HTML document describing the model or exporting the graphical representations of the designed system However for a suitable support of the development process it is important to have a flexible generation of documentation e g by selecting format of the documentation DOC vs HTML or the degree of detail interface description vs complete opera tions 3 1 2 Development Process The CASE tools investigated in this case study focus on the middle phases of the classical cascading development process Most support is avail able for detailed design and implem
160. esponding class was introduced In addition the main use cases were represented by controller classes The first model was improved during several team meetings and discussions As soon as the class model was stable enough we got into the details of modeling the object interactions on the class level These object sequence diagrams were an enhancement of the already designed object sequence diagrams on the use case level In an iterative process we detailled the class diagram with the needed methods operations At last we designed state machines for the most complex classes based on the corresponding object sequence diagrams class level Also here we could improve the class diagram and find the last methods attributes and constants We finished our design process refined all models especially the class model and searched for possible inconsistencies Last but not least we stepped into the test process To simulate our state machines we used the state machine generator in combination with Altia Faceplate 5 3 2 Process Support Simple development operations All standard well known operations are supported by ARTISAN Realtime Studio e g copy paste or drag n drop These functionalities are available in all different diagrams For example it is possible to copy and paste the descriptions of the use cases to the corresponding object sequence diagram An undo function with a large undo stack is provided by ARTiSAN Realtime Studio see R
161. explaining as almost all features for a specific function component can be accessed by right clicking the mouse It is very easy to get familiar with the basic fea tures the tool offers such as creating a new project modelling it gen erating code and debugging These basic features are well introduced in the tutorials Further knowledge of features and a deeper under standing of the whole functionality of Trice is gained through using the tool The basic appearance of the integrated development envi ronment IDE is clearly structured Only one project can be open at atime Nevertheless many different views of this project can be open at the same time This is useful for example when modeling the be havior of a component actor because it is possible to have a view of the state machine of the components structure and the commu nicating ports and interfaces of that component Additionally to the views there are several anchored bars visible workspace bar output bar system tool bar behaviour tool bar Through these bars you can easily access the tools functions For example the workspace bar con tains a classes register card that shows the projects actor protocol and data classes For each of these classes and its elements it is possible to directly access the context menu The appearance of the bars can be configured independently 12 2 MODELING THE SYSTEM 229 12 2 Modeling the System 12 2 1 Available Description Techniques S
162. face to DOORS 12 2 3 Complexity of Description Views We have about 100 different views in our system including 1 struc ture view per actor instance 1 data view per actor and 1 or more in case of hierarchical state machines behavior views per actor Nodes In each view we have approximately between 1 and 20 different nodes actors instances states Edges We have between 0 and approximately 50 edges per view Visible annotations Most annotations are visible in Trice or could be se lected visible by user for example action and trigger codes Invisible annotations Only a few annotations in Trice are not visible about 10 from all in our case 12 2 4 Modeling Interaction Supported communication model Trice is fully event driven using a ports and connectionsmodel Data transfer methods are irrelevant for Trice modeling and can be implemented in different ways depending on target platform for example CAN C variables pointers ethernet Communication model suitable The notation and modeling techniques are well suited for our case study Timing constraints Timing constraints are irrelevant for Trice based mod eling due to a high abstraction level Sufficient realtime support Real time support was fully sufficient for case study 232 CHAPTER 12 TRICE TOOL BY PROTOS SOFTWARE GMBH 12 3 Development Process 12 3 1 Applied Process Give a short summary of the development as performed in the CASE study For
163. g an extra flow chart for it On account of this we were able to avoid overload Another reason affecting us to use state charts was that state charts provides the opportunity of using static reactions Static reactions are not visible in the model but only in the data dictionary That is the reason why clearly arranged modelling was rendered possible The notations and diagram types offered by Rhapsody were fully suit able for modelling the case study thus there were many notations we did not use in our project e g flow charts truth tables and generics There was no need using these techniques because the state chart concept was completely adequate Generally the user has the possibility to keep even complex models readable by using techniques like hierarchy By embedding subcharts into one s charts the developer can start at the top level defining only the main structure and data flows and keep moving down the hierarchy implement ing more and more details of the model 9 2 3 Complexity of Description This section provides an estimation of the size of the built model The whole project covers 14 views including 105 nodes and 150 edges overall Nodes are states and activities edges are transitions and dataflows Each view state charts and activity charts is made up of 7 nodes and 10 edges at an average The biggest diagram consists of 16 nodes which are con nected by 25 edges with each other The size of each visible annotations i e
164. g with timers Hierarchy Tau supports various kinds of organizing the model in an hi erarchical manner The whole project is represented as a tree struc ture in the left window This tree contains all information about the project At the top of the hierarchy there are the packages used in the model One package contains the main class where all the dia grams describing the main class are in It also contains other classes used by the main class and global variables The classes contain dia grams themselves thus continuing to branch recursively In the tree view under each class node there are element nodes For example parts are attributes of a class used by the class in its architecture dia grams The diagrams themselves contain all information represented by their graphical nodes The only thing that was confusing is that you define classes within a node of a class that contains objects parts of that classes But of course you could also define a package for all kinds of classes needed more often and in different stages of the hierarchy e g helper classes and avoid this problem 208 CHAPTER 11 TELELOGIC TAU Furthermore hierarchical description techniques like aggregation and composition are supported One thing to mention is that in our pre liminary version of the tool state chart diagrams can not be nested within each other thus enabling hierarchically organized state charts what might be useful in complex action flow
165. ght door doesn t unlock its controller send a CAN message ERROR_KEY and so the left controller locks the door again switches on the motors and off after the bar is locked Testing the Manual Seat Adjustment In this scenario for testing the manual seat adjustment we wanted to prove the correct function of the semaphor which controlls that only two direc tions can be adjusted at one time and the automatic stop of seat movement if the movement limit for this direction is reached This scenario is realized by the input data in table 8 4 which results in the output data shown in table 8 5 150 CHAPTER 8 MATLAB STATEFLOW t in RIE OF KL_15 MO BATT ER _KEY GEL FEN ST TOR ROR STA _LFT _KEY m 11 11 11 11 11 11 11 11 11 11 MOOoOoNON UVMPrONDHM ooooocoooNoco 4 PRR rR OOrRrR BR OS 9595 5 95 9 cOcoccccocccocccOco So O S OS oco cOoocococcoccocmoocc e Table 8 2 Input data for the door locking test t out out out out out P out out _ZV _BLINK _DU _ER _LOW _ZENTR _WIN _SCH RA ROR _KEY _MOT _VL _L TION _KEY _CL 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 2 1 0 0 0 0 12 0 3 1 0 0 0 0 12 0 4 1 0 0 0 0 12 2 5 1 0 0 0 0 12 2 6 1 15 50 0 0 0 2 7 1 15 50 0 0 0 2 8 1 15 50 0 0 0 2 9 1 15 50 0 0 0 2 10 1 15 50 0 0 0 2 Table 8 3 Output data of the door locking test 8 5 MODEL OF THE CONTROLLER
166. gram type for modeling var ious scenarious Elements used Diagramtype not used mond Component Node Small circle unused General Flow Box Softbox Circle Ellipse Parallel Dia Type of notations Almost all diagrams are graphical with additional text elements An excep tion is of course the Text Diagram Hierarchy It is possible to interlink various diagrams and to create sub diagrams for single elements of a model The interconnection between the diagrams can be hierarchically structured 5 2 2 Applied Description Techniques During modeling the case study some but by far not all features of ARTi SAN RT Studio had been used Used notations unused notations as well as some experiences are described in this section Detailled informations about used and unused diagram elements are shown in section 5 2 1 58 CHAPTER 5 TOOL ARTISAN REALTIME STUDIO Applied notations The diagrams we used for modeling our system were e System Architecture Diagram e Use Case Diagram e Class Diagram e Sequence Diagram e Constraints Diagram e State Diagram Modeled aspects According to the offered modeling aspects we have designed the interfaces on a System Architecture diagram The behavior and interaction were de signed in several State and Sequence Diagrams based on a Use Case Dia gram In one Class Diagram the structure of the system is shown Notations suitable The used notations are suitable f
167. h it Error messages in AUTOFOCUS often don t help to find the error but cause more confusion If a transition is not well formed the error messages most of the time gives no hint where to look You have to find out the error by looking through the whole transition which can be because of the DTD concept very long AUTOFOCUS provides consistency checks which are sometimes too correct That means the simulation or the model is allright and should run but run ning the consistency check leads to error messages which are confusing and misleading Another weakness which could eventually be a feature is the fact that all DTDs have the same namespace That makes naming conventions essen tial but if you give a data type in one DTD the same name like in another DTD by mistake no error message is written 7 5 3 Desired features At last we considered it as a good idea to specify some features we would like to have in AUTOFOCUS A version control would have been important for us while we worked on our model Because of the instability accessing and restoring older versions would have helped us a lot An undo function is another desired feature not implemented yet Deleting components ports channels etc forced us to draw them again The client server architecture helped us a lot but if one of us opened a view for editing it no other user could access the view If that user just wants to read the information it should be possible in a re
168. harts Events and Conditions Beyond this Rhapsody supports the constructs Events which can be divided in primitive events compound events and derived defined events conditions exacting primitive compound and defined conditions 9 2 MODELLING THE SYSTEM 163 Hierarchy For complex systems many pages of activity charts will be nec essary this again is a strength of Rhapsody in MicroC as functional hierarchy is easily depicted using off page charts This concept is available in both activity charts and state charts 9 2 2 Applied Description Techniques During the whole process we used the following notations Use case di agrams and sequence diagrams during the analysis phase Use case dia grams to visualize the structure of usecases see fig 9 1 Sequence diagrams rendered us possible to picture single usecases see fig 9 2 This kind of di agram facilitate the developer to compare his final implementation to the requirement analysis In the design phase we used activity charts and state charts By the use of activity charts the basic structure of ones project is specified for example see fig 9 9 Most of the functionality of our model is implemented through the state charts here you can see an example in fig 9 11 The main reason of using state charts was the possibility of working with this kind of chart From our point of view behavior can be pictured much more efficient by writing action syntax into the state automata than drawin
169. harts and shared variables Maybe several aspects could be modelled more efficiently by using also for exam ple generics or flowcharts 172 CHAPTER 9 RHAPSODY IN MICROC SITZPOSITION SIT2VERSTELLTASTER SITZHOTOREN 3 Bene b nnnTn Uter 777 SENUTZERHGHT THSTER TGRIFFLEISTENSENSOR LGRIFE NTR NOTI ZLNIE PHILO s TUERSCHLOSS T RIEG STUERVERRIEGEL NGSSENSOR CAN_S_OUT CAN_S_IN Figure 9 9 Top level activity chart TSG_MAIN In conclusion RiMC is as a very multifunctional tool supporting nearby all kinds of ideas for designing a model but it takes some time to get famil iar with it Moreover the handling difficulties lead to additional troubles 9 5 Model of the Controller The functionalities of the different modules of the controller are divided into various activity charts which build up a tree like structure The root component of our model hierarchy is the activity chart TSG_MAIN which defines the main internal modules environmental activities and the data flows between them A screenshot of the chart is depicted in Figure 9 9 The functionality of the controller is mainly divided into three compo nents As every component has it s own activity chart charts BENUTZER MANAGEMENT SITZSTEUERUNG and TUERSTEUERUNG they are black boxes in the chart TSG_MAIN The environment of the controller i e but tons sensors the CAN bus etc is represented by environmental activi ties In the following parag
170. he constraints described in the specification This is done in the Plug 2 input splitter the movement control and in the user control subsystem part for the po sition commands received from the user control The automaton for the seat movement is one of the key components Fig 7 6 where also the error handling takes place There are two ways how a movement request can reach those automatons One way is a direct request by the user if the user presses a movement but 7 4 MODEL OF THE CONTROLLER 119 canMsgin CanMsginDTD tomplSeatPos1 CompleteSeatPosDTD complSeatPos2 CompleteSeatPosDTD plug1Msgin Plug1 MsginDTD complSeatPos3 CornpleteSeatPosDTD yO complSeatPos4 CompleteSeatPosDTD userControlCommand1 UserControlCommandDTD plug2Msgin Plug2M sginDTD finished1 Bool cormplSeatPo s Corpletet atPosDTD userControlCommand2 UserControlCommandDTD o plug2M sgIn Plug2MsgInDTD finished2 Bool userControlCommand3 UserControlCornmandDTD plug2Msgin Plug2MsginDTD finished3 Bool finished4 Bool plug2M sgin Plug2M sgInDTD userControlCommand4 UserControlCommandDTD userManagementCommand UserManagementDTD sep e Figure 7 7 UserControl component ton and another way is a position load request The latter one is processed in the user control subsystem of the Seat Control part If the requests source is the door key all seats are moved at the same time if
171. he function of the user management the other class performs the adjustment of the seat Both components have to communicate with each other therefore they are put together in one module see Fig 6 14 on page 94 They are realised both as block diagrams The user management con sists of a rather complex entry logic that decides the action to be per formed and a store that saves up to four seat positions In contrast to the entry logic the store is modelled as a independent class Im portant to annotate is that the store contains a hierarchy of subclasses These classes are essential for the accurate functionality of the whole component but in this section a detailed description of them is not worthy of mention A seat position can be stored in one of four store positions Such a store position is modelled by a class which is in stantiated four times Every store position offers place for five val ues from which each one represents the position of an axis of the seat For every value there is needed an instance of a class which en ables to save a single value To read a stored position there are needed five instances of a multiplexer class see Fig 6 18 on page 98 These values read by the user management will be transmitted to the seat adjustment Ditto transmitted are a start signal which commands the seat adjustment to start its work and a signal which tells if the seat adjustment was triggered by the radio transmitter The
172. hich can be precondition input port output port postcondition priority The input ports specified define on the one hand data wich can be used in preconditions or written to an output port On the other hand the pure presence or absence of a value can be checked as well A transition can consider preconditions for the input values or local variables stored in the appropriate SSD It also can define postconditions for the local variables which means that those variables have to adopt new values At last the priority of the transition is a instrument to make a STD de terministic because it can be defined which transition is used if there are multiple choices This is very useful if you have to consider special cases 104 CHAPTER 7 AUTOFOCUS Modelling aspects System structure diagrams SSDs enable the socalled structural view It shows the components and also their interfaces through the channel port concept which have user defined types determined in the DTDs The interaction view can be found in the ex tended event traces EETs where the communication within the sys tem and between the environment and the system is described Then we have the data view in the data type definitions The behavioral view is shown in the state transition diagrams STDs which help to de scribe and to determine the manner of each component It shows the used input values or local variables and the calculated output mes sages
173. hine offer the possi bility to monitor states and events during runtime Operator inter vention is also possible during the running process This means for example that remote servicing and intensive cooperation is possible Debugging Features For debugging our model we used message injec tion runtime display and manipulation of variables message sequence charts MSC recording visualisation of state machine execution trac ing Debugging is completely on modeling level However it is possible to use an existing debugger on the target platform at the same time as using Trice modeling tools Testing Testing can be accomplished by using the ROOM method itself There are also static analysis techniques available interactive formal methods No automated tests are provided As well Trice is delivered with a simple testing interface for simula tion showing the inputs and outputs Certification Generated code is not certified but the process has been started with TUV Requirements tracing There is no integrated support for requirements trac ing however there is an interface to DOORS integrated into Trice We heard of this feature at the end of our modelling so that we could not use it 12 3 DEVELOPMENT PROCESS 235 12 3 4 Applied Target Platform Target code generation Trice supports the target code generation for mul tiple target platforms Supported targets Trice runs on Windows NT and Windows 2000 The code ge
174. hnitt wird ein kurzer berblick ber die Funktionalit ten und Eigenschaften des TSG aus Benutzersicht gegeben Eine detaillierte Beschreibung der einzelnen Funktionalit ten findet sich in Abschnitt 5 In Zweifelsf llen gelten die Beschreibungen in Abschnitt 5 2 1 Absatzmarkt Der Einsatz der beschriebenen Komponente ist f r die Baureihe STAL 390 Coup 2 T ren geplant Die Markteinf hrung ist f r das 3 Quartal 2003 geplant Die erwarteten St ckzahlen betragen ca 20 000 Einheiten pro Jahr 2 2 Kurzbeschreibung der Komponente Die in diesem Lastenheft beschriebene Komponente wird als T rsteuerger t bezeichnet kurz TSG Gegenstand der Modellierung ist das TSG der linken Fahrzeugseite Dieses TSG kommuniziert mit einem TSG auf der rechten Fahrzeugseite Das TSG wird in einem Fahrzeug mit zwei T ren verwendet Das TSG bernimmt folgende Funktionen im Fahrzeug Sitzeinstellung Verstellen des Lehnenwinkels der horizontalen Sitzposition der H he des vorderen Sitzbereichs der H he des hinteren Sitzbereichs und der Schalung des Sitzes Benutzermanagement Benutzerspezifisches Abspeichern der Sitzposition T rschlo Auf und Zuschlie en des Fahrzeugs ber Schl ssel Funksender oder CAN 2 3 Periphere Komponenten In Abbildung 1 ist das TSG zusammen mit seinen peripheren Komponenten in einer schematischen Zeichnung dargestellt Die hellgrau unterlegten Teile der Abbildung beschreiben die Funktionalit ten des TSG
175. how component instances use the deployment diagram Type of notation The representation type of the notations e use case diagrams Graphical notation A use case diagram is a graph of actors use cases use case packages and the relationships between these elements e class diagrams static structure Graphical notation The basic notation for elements in a class diagram is using a solid outline rectangle with three com partments separated by a horizontal line The top compart ment is used to display the name of the element and other optional properties such as stereotypes and icons The bot tom compartments or list compartments are used to show string representations of an elements features For example operations and attributes are commonly represented How ever other optional list compartments can show other fea tures For example a capsule has a list compartment for ports and capsule roles e state diagrams Graphical notation A statechart diagram represents a state machine The states are represented by state symbols and the transitions are represented by arrows connecting the state symbols States may also contain subdiagrams other state machines that represent different hierarchical state levels e collaboration diagrams dynamic structure 186 CHAPTER 10 RATIONAL ROSE REALTIME Graphical notation A collaboration is shown as a graph of classifier roles together with connected lines called associa t
176. ibed We again divided the TSG component into four components Door Control Seat Control and User Control Fig 7 2 which were required in the case study paper Our model also contains some Merger components for the splitting and merging of messages which was necessary because we decided to design the messages according to the sources and targets as n T uple so a chan nel contains a set of data The splitter then extract the needed data from the Tuple s to make it easier to handle it if only a subset is needed 7 4 1 Door Control The Door Control component is used to manage all actions that relate to locking or unlocking the doors It doesn t have any interaction with the other two major components the Seat Control and the User Control Now I want to describe how the Door Control works in detail At first it must be determined if a locking or unlocking action takes place Such a signal could either come from the CAN Bus or from the Plug 1 signaling that the key was used to lock or unlock the door It is also important to detect errors in incoming messages If these signals show signs of inconsis tency the doors have to be opened The whole signal detection is done in three subcomponents of the Door Control Every one of them is responsible 7 4 MODEL OF THE CONTROLLER 115 UserControl SeatControl DoorControl plug2Msgin P2Msgin SBNane SBNone SBNone SBNone SBNone SeatPosValue 2 0 SeatPosValue 1 0 SeatPosV
177. ichten kann angenommen werden dass der Interaction Layer aus sporadischen SendMessage Aufrufen zyklische CAN Botschaften erzeugt falls erforderlich In der OSEK COM Spezifikation wird dies als Periodic Kommunikation bezeichnet Die Funktionalit t des Interaction Layer sowie der darunterliegenden CAN Kommunikation muss also nicht notwendigerweise im Modell spezifiziert werden Falls in der Spezifikation spontane CAN Botschaften gefordert sind kann dementsprechend das Direct Kommunikationsmodell modelliert werden 6 3 2 2 Empfangen CAN Botschaften k nnen vom Modell entweder aktiv abgefragt werden z B durch Versenden einer entsprechenden ReceiveMessage Nachricht an den Interaction Layer oder passiv empfangen werden z B durch Empfang einer entsprechenden Message in der Modellierungssprache des CASE Werkzeugs 24
178. ick Abbildung 9 Steckerbild S3 Anschlu Bezeichnung In Out Beschreibung l MASSE Signalmasse 2 V CC 12 V Versorgungsspannung 11 Bordnetz 5 CAN B LOW In Out CAN B Innenraumbus Low 6 CAN B HIGH In Out CAN B Innenraumbus High Tabelle 4 Steckerbelegung S3 Nachfolgend werden f r die einzelnen Signale deren Charakteristiken detailliert beschrieben CAN B Bus Anschl sse 5 CAN B LOW 6 CAN B HIGH Charakteristik Anbindung an den Innenraumbus gem ISO 11519 bertragungsrate 83 333 KBit Anbindung ber Differenzsignal Die Botschaften die ber den CAN Bus bertragen werden sind in Abschnitt 4 definiert 3 3 Elektrische Spezifikation Die Betriebsspannung des TSG liegt zwischen 9 0 V und 13 5 V Die erweiterte Betriebsspannung Ansteuern der Aktuatoren nicht notwendig liegt zwischen 7 5 V und 16 0 V Im aktiven Zustand darf der Stromverbrauch ohne aktive Aktoren 500 mA nicht berschreiten Bei aktivierten Aktoren darf der Stromverbrauch entsprechend h her sein siehe dazu die Beschreibung der einzelnen Ausg nge 3 4 Geh use F r das Geh use gelten die maximalen Abmessungen von Bx Hx T 220 mm x 185 mm x 34 mm Die in Abbildung 10 eingezeichneten Befestigungspunkte sind zu beachten Weitere oder ge nderte Befestigungspunkte sind nur nach Absprache mit dem Auftraggeber zul ssig ne 220 mm eS TEN UR Raine i RY ae ada ied Aaa ies
179. ies as needed All active objects in the system were modelled in the form of actors for example an actor can represent the soft ware part of a closing action a motor of a door or also portray a complete functionality Sitzsteuerung forming one part of the whole case description Also it is easy to create new actors but we preferred to reuse similar components as much as possible e g left and right door The same applies for state machines which can implement very com plex behaviour Trice supports the hierarchy and abstraction concept introduced by ROOM Each state of a hierarchical state machine can contain a whole state machine and so on recursively 12 2 MODELING THE SYSTEM 231 Unused notations We did not use the concept of Primitive Classes in our model Primitive classes are an extension to the ROOM language in troduced by Protos Software GmbH Primitives are passive compo nents intended to encapsulate low level and frequently used func tionality The model just can send simple commands to the primitive These commands are defined as incoming messages in a protocol which is exported by the primitive class The reason for not using primitive classes was that we never felt the need for using them Other features we did not use were inheritance and transaction guards Missing notations The only feature which is not formally provided by the tool is the integrated requirements elicitation support However there is an inter
180. igure 11 12 While building up a diagram only UML 2 0 compliant elements can be added For example in a state chart diagram you can connect next to a state just an incoming signal but no different element When an element is selected elements which cannot be added are grayed out If you try to connect components that do not fit the connection is refused or marked red Semantic consistency Besides the automatic syntax ensurance mechanism a manually evokeable check button is provided With the button s check function you can find more warnings and errors By double clicking on the error message you jump directly into the view where the erroneous class state or variable is defined or used 11 3 DEVELOPMENT PROCESS 217 Information Checking Session Eil test ttp Information Session 0 error s 0 warnina s Information Checking Diagrams Figure 11 12 Autocheck Not only the before mentioned syntactic errors are displayed but also some elementary semantic information warnings and er rors For example all signals that are sent from a part should be defined as incoming or outgoing signals of a port and the chan nel where the signal is sent should be defined as a connection between two parts in an architecture diagram Before running the simulation there is another extended syntax and semantic check caused by the build button Component library bus Is a predefined component There are two
181. ile or the MATLAB workspace with special blocks from its component library This data can then be fed into the Stateflow model to provide it with test input In the same way your model s output can be written into an array a matrix on the MATLAB workspace or directly to a file Additionally there are two tools for further analysis e Profiler The profiler can be used to measure several character istic data and give you thus hints for possible further optimiza tions It generates a profile report which is saved in your work ing directory e Model Coverage Tool The model coverage tool provides you with the ability to define test cases run them on your model and analyze afterwards what percentage of your model was covered by this test This tool outputs a report in HTML format and lets you specify the amount of details the report should have The generated test cases can be saved to and reloaded from files Additionally if you open the debugger Simulink Stateflow displays the coverage of the model It is also possible to interface Simulink with Rational Test RealTime for further testing purposes Certification The code generators in RealTime Workshop are not certified in any way The MathWorks explains this by the fact that their code generators are thoroughly tested and certification is of no particular advantage they say that certification takes a lot of time and that one has to certify the generated code in its specific context
182. ily copy move connect etc components with the mouse The menus are clearly structured and one can easily guess what functionality lies behind a certain menu entry All of the dialogues are pretty comprehensible for an unexperienced user too One thing to criticize is that the buttons in the tool bar are not really intuitive Also the handling of transitions in Stateflow can provide some problems if you want to structure your model to make it more readable you ll have to put some effort into it until you can arrange the transitions so that you have few crosses and transitions which are good to read the tool provides no function to automate this Finally during our work it happened some time that states or functions dis appeared from the model i e that after navigating in the model there were only empty states functions or that they had been deleted com pletely In conclusion you can get along quite well with the tool 8 2 MODELING THE SYSTEM 125 8 2 Modeling the System 8 2 1 Available Description Techniques Supported notations Simulink Stateflow offer graphical and non graphical notations The graphical ones are e Stateflow s state transition diagrams consist of states transitions between states junctions which can be used to connect transi tions and graphical functions they look quite like UML state charts e Block diagrams in Simulink are composed of different blocks sinks sources linear and nonlinear components
183. in a proprietary format So third party plug ins for a simulation on different target platforms could be available in the future Adequacy The model verifier generates sequence diagrams during simu lation These can be compared with the diagrams build during the requirements analysis process and checked for inconsistencies The automatically generated sequence diagram contains all objects mes sages and timers and becomes rather huge as the system increases But one can manually hide unused objects and hence make the de scription more readable Debugging Features Nextto the syntactic and rudimentary semantic check ing discussed in the last section under Consistency ensurance mech anisms there are other debugging features which are applied in the testing phase During the simulation with the model verifier you can inject signals that initiate TSG actions You can run the simulation stop and con tinue it at any time or proceed step by step It is also possible to define breakpoints and let the simulation run until this point This can also be monitored in a state chart diagram All variables sent within a signal can be examined directly in the sequence diagram see upper right window in Figure 11 13 The variables checked during the tran Figure 11 13 Model Verifier 11 3 DEVELOPMENT PROCESS 219 sitions are displayed in a sepa
184. ind an explanation of debugging and error messages The UML2 standard is not released yet so literature on that is not available The UML2 standard differs considerably from the UML1 x standard For this reason it was difficult to have an explanation of the new concepts Therefor the main reference were the example programs provided by Telelogic Usability The user interface is very comfortable to work with It provides a typical MSWindow application environment with three windows integrated in the main window see Figure 11 1 The window on the left is the tree view similar to the MS Explorer where you can visu alize the model s structure On the right side you have a graphical representation of the node that is selected in the tree window At the bottom there is a debug window that indicates information warn ings and errors 11 2 Modeling the System 11 2 1 Available Description Techniques Supported notations All basic UML 2 0 notation concepts are supported by the tool Use cases use case diagrams class diagrams sequence 11 2 MODELING THE SYSTEM 203 startMGMT1 C Dokumente und Einstellungen hain Desktop Case20030122 test testu2 OSE BX oo S vw jr fbe IE Aeewensae z af Ee ROS e ORS SSS TNS Bx 9 8 38 5 s ze alee ae v sla a n mn stanMGMT1 statemachine initialize 5 8 begin MGMT_1 r gt 100 x StatMGMT Soll HOR Solli_W Sol
185. inement or behaviour This test is im portant to find errors that make it impossible to simulate the system Are all the ports connected and are all the channels bound Do all components have an unique name Can the automatons be flattened Are the transitions connected The checks are grouped by SSD STD and ETT tests and split up in inter and intra component behaviour The better way of checking the consistency with AUTOFOCUS is to simulate the system Still the consistency checks may be necessary to get the system to simulate With this graphical test errors can be detected easily Here it is also possible to simulate a subsystem This works good and we couldn t find errors like in the standard consis tency check here When a new Transition is created the correctness of the parameters can be checked there The DTDs may be parsed on creation This check is very useful but could be implemented better A problem arises when DTDs are split up into more documents AUTOFOCUS has then difficulties in finding the corresponding data This problem can be avoided when import DTD statements are used This check also revealed a weakness of AUTOFOCUS AUTOFOCUS has problems handling variables with the same name even if they are part of different complex datatypes This makes it necessary to label the variables very carefully like in cluding a prefix for the complex datatype A good idea for the next version of AUTOFOCUS would be to color
186. ion and therefore it can be instantiated only once In modules there can be defined many processes All components in each module whose execution point in time takes effect to the re sult have a sequence call number and are assigned to one of these processes see Fig 6 3 page 77 Such components are if statements variables send messages classes etc As the name implies this se quence call determines in which order the components are called Every process can be stimulated at different time cycles so different parts of a control algorithm may be computed at different times For data exchange the modules use messages see below Classes If a special functionality or model sections are used more than once in a module then they should be encapsulated in classes or state machines Classes can be structured hierarchically and commu nicate with the environment modules or parent class on the basis of methods and their parameters and return values In opposition to 6 2 MODELLING THE SYSTEM 77 able DD e valuaf n store m gt Labo c a vm m if statements store buffer feturnfout Figure 6 3 Sequence calls modules it is not possible to define processes so every instantiated class gets its own sequence call number and has to run at one time cycle Fig 6 4 on page 77 shows over again the relationship between the structural constructs enumerated so far Figure 6 4 Relationship between the structural constructs State m
187. ion of a message signal or some timing event Time treatment access to clocks or use of timers producing timeout events is available to deal with weak real time constraints They differ however concerning the level of abstraction from the im plementation they use Some tools rather consequently use this abstract 3 2 MODELING THE SYSTEM 27 model e g AutoFOCUS Matlab Simulink Rhapsody in MicroC Telelogic Tau Trice others at least partly keep the implementational view model ing components e g by object communicating by method call e g ARTI SAN This is reflected in the description techniques as well as the opera tional model supported by the tools 3 2 1 Available Description Techniques All tools support four common classes of description techniques Structural Descriptions describing the architecture of the system consist ing of components interfaces e g ports sensors actors communi cation paths e g channels connections Examples are System Ar chitecture Diagrams in Artisan or Block Diagrams in ASCET SD State Based Descriptions describing the behavior of the system using states transitions actions or events and timing annotations Examples are State Transition Diagrams in AutoFOCUs and Matlab Simulink dif ferent variants Scenario Based Descriptions describing exemplary execution sequences consisting of interactions between components or their continuous data flow e g in an Oscilloscope
188. ion roles e capsule structure diagrams Graphical notation A capsule structure is shown as a box with a heavy border which represents the capsule s bound ary Capsule roles are shown inside the boundary as com posite parts Ports are shown as rectangles and connectors as solid lines connecting ports e sequence diagrams Graphical notation A sequence diagram has two dimen sions the vertical dimension represents time and the hor izontal dimension represents the different objects in the in teraction e diagrams deployment diagrams Graphical notation A deployment diagram is a graph of nodes connected by a communication association called a connection The deployment diagram is used to show which components will run on which nodes e component diagram Graphical notation A component diagram is a graph of components connected by dependency relationships Com ponents can be connected to components by physical con tainment representing composition relationships Hierarchy The notation support hierarchical structuring e The states in statechart diagram may contain subdiagrams other state machines e An aggregation hierarchie can be represented in a class diagram e Structure diagrams represents the composite structure of its cap sule roles ports and connectors This example from the case study model show the Hierarchie in a sturcutre diagram 10 2 MODELING THE SYSTEM 187 SBPort Oontrolleri l y s
189. ion trace of the implemen tation level This leads to increased process efficiency by a higher degree of automation as well as increased product quality by elimi nating defects introduced by manual development steps Recent analysis suggests that currently available CASE support does in deed lead to a significant increase in productivity However especially in the field of automotive industry the increase of system complexity has grown faster than the increase in productivity for the last 10 years As ar gued above model based development promises to help closing this gap by shifting analytical and generative techniques from the level of imple mentation to the level to specification and modeling Current research e g PLP03 SBHW03 shows that model based tool support is technically feasible Bibliography BMJH96 Tilmann Bruckhaus Nazim Madhavji Ingrid Janssen and John Henshaw The Impact of Tools on Software Productivity IEEE Software 13 5 29 38 1996 Jon91 Capers Jones Applied Software Measurement Software Engineer ing Series MacGraw Hill 1991 48 CHAPTER 4 MODEL BASED DEVELOPMENT PLP03 Alexander Pretschner Heiko L tzbeyer and Jan Philipps Model Based Testing in Incremental System Development Jour nal of Systems and Software 2003 SBHW03 Bernhard Schatz Peter Braun Franz Huber and Alexander Wisspeintner Consistency in Model Based Development In Proceedings of ECBS 2003 10th IEEE Internatio
190. ions would be A 100 B 15 and C 32 Another very important feature is the auto document generation which allows to create a document of the model or of selected parts of it The resulting file can have different formats like PS or HTML and can be generated in German or in English It contains the layouts and screenshots of the components lists of their elements messages and methods and implementation information If the user has added some comments then they are also included During the development phases we used all of them Reverse engineering In parallel to the generated C code an ASAM MCD 2MC description is required It provides the necessary address in formation for application and measuring systems This is obtained by reading back and interpreting the MAP file after generating the program The ASCET SD Target Integration Package contains this function You can even start from an ASAM MCD 2MC file read it into ASCET SD and base a first data model in ASCET SD from it re engineering an existing program For the modelling we did not need this feature User support The tool offers no design guidelines or context dependant process activities Very useful is the configuration window which can be opened when a new variable or constant is defined Consistency ensurance mechanisms ASCET SD offers no consistency en surance mechanisms but contains a helpful mechanism to find com pilation errors in the model Error and war
191. is case the model reads out the memory to get the position the seat should be adjusted to and send it to the seat con trol unit At the same time the memory is read out the state AUTOMA TISCHE_VERSTELLUNG is entered This state contains two nested state 174 CHAPTER 9 RHAPSODY IN MICROC AUTONATISCHE_VERSTELLUNG not MGHT_SET and tr HGHT_1 tr CBNHG J SPEICHERN ind te MGHT_4N POS MGHMT1 V2H I POS HCI IT1 Hs 1 H R ACHSE_HOR_CNTF AR iid HOR E hd LACHSE VI TCR POS and LACHSE H CNT H I Mer not MGMT_SET an V POS HGHT3 VH I not MGH SETI and und FD HOR T3_ H3 BNHG CBNHG_INTERRUPTp HOR POS HGHT4 HOR7 V POS HGHTM PDS MGHT4_Hstr BNHG_STEUERUNG gt 7 s Y 4 nel ee STKE jja ins S TIZ de joe z D i F KEW la DZM HGH trcMGMT_ HGHT4_W 4 MGMT4_S RUNG gt tr CBNMG_START gt ACHSE_V_CNT V_POS and LACH9 amp H a CACHSE_ POS and CACHSE S_CNT S_POS and LACHSE_H_CNT H_POSI Fs CBNHG START s CBNMG_STEUER Figure 9 11 State chart BENUTZERMANAGEMENT C charts to increase readability of our model In the first nested state chart BNMG ST OP see Fig 9 12 the opening movement of the axes is performed with only two axes moving at the same time Therefore this chart consists of a single superstate which contains two parallel state series Every series performs the movement of all the axes in the required order To ensur
192. isms are available We will discuss I O synchronous clock synchronous unsynchro nized and event driven mechanisms I O synchronous I O synchronization of parts is supported using the follow ing two symbols in state charts see Figure 11 8 The transi Eingehendes Signal Y Ausgehendes Signal Figure 11 8 An incoming and an outgoing signal tion only works if there is an incoming signal and then sends immediately the second signal But this is like triggering an event when a signal comes in As far as we know higher synchronization concepts like semaphores or monitors are not available However we were successful by implement ing a semaphore clock synchronous There is a system wide clock available with which to syn chronize signals You have the possibility do define timers see item below unsynchronized event driven Signals are stored in a queue and processed in the order they are stored in the queue If you don t implement any syn chronization mechanisms by yourself event scheduling is unsynchronized and therefore also the event driven actions are 11 2 MODELING THE SYSTEM 213 e Shared variables vs messages Using signals you have the possibility to graphically model in teraction We modeled the whole internal communication well as the communication with the environment by sending and re ceiving signals As you can integrate C C code into all classes and also the methods that are represen
193. ither in state door locked or door unlocked or follows a way of states from door locked to door unlocked or vice versa see Fig 6 13 on page 92 User management seat adjustment The user management communicates with the seat adjustment therefore they are put together in one mod ule The user management get its input signals either from the but tons pressed by the user in the car or from the radio trigger used outside the car Ditto the user management is injected with the actual seat position respectively with the values of the five axes of the seat A rather complex entry logic determines the operation to execute and 98 CHAPTER 6 ASCET SD their priority Such operations are save a position triggered by user button or CAN message and read a saved position and send it to the seat adjustment triggered by user button CAN message or ra dio transmitter see Fig 6 18 on page 98 In addition to the entry logic the user management has to contain a store component in which the seat positions can be stored The user management is able to store a seat position at more than one store po sition at the same time So if the user wants he can fill the whole store with the current seat position in a point of time In contrast to this only one stored position can be read from the store at the same time and transmitted to the seat adjustment If the user or the system tries to read more than one stored positions no valid value wi
194. itz vor zunieckR1 j sitz steiler flacherR1 Coptfolleri F controllerR1 schalung enger weiterR1 b Controlbr3 S1ASPort S1ASPart 7 CASPort D flaeche_hinten_sinken_hebenR1 Controller4 flaeche vorne sinken hebenR1 Controller5 10 2 2 Applied Description Techniques Applied notations We used during modeling the case study the following diagrams use case diagrams class diagrams static structure State diagrams capsule structure diagrams oF Cc N e sequence diagrams Modeled aspects the following aspects have been modeled in our case study 1 behavior described in state machines They models the behav ior of a particular capsule For example the state machine at page 21 depicts the behavior of the BenutzerManagement capsule 2 structure described in class diagrams structure diagrams use case diagrams Sequence diagrams They show the static struc ture of the model For example the class diagram at page 3 shows static structure of the TSG capsule 188 CHAPTER 10 RATIONAL ROSE REALTIME 3 interaction Interactions model the dynamic aspects of a model They have been modeled in sequence diagrams and structure diagrams in which a pattern of communication between objects have been specified For example the structure diagram at page 9 shows the set of interactions in the SitzEinstellung capsule Notations suitable the notations are suitable for m
195. k signal comes the focus switches to another hierarchical state 6 5 MODEL OF THE CONTROLLER 97 that checks the battery tension If the voltage of the battery is high enough the state motor control becomes active else the whole op eration cannot be executed and will be cancelled The door remains locked Motor control is a hierarchical state too in which the mo tors of the door latch are triggered The special feature of this state is that it is used to unlock and also to lock the door So there is only one state needed to execute two different operations If the operation was successful a CAN message for blinking lights will be generated in another state Immediately after that the new active state will be door unlocked If the operation failed the door remains locked the active state is door locked see Fig 6 17 on page 97 hierarchical state see structure of the state machine hierachical states Figure 6 17 Functionality of the centralised door locking Locking the door acts the same way but in the opposite direction In this case the active state is door unlocked A signal to lock the door occurs The battery tension is checked the state motor control will lock the door A CAN message for blinking lights will be generated and the state machine goes and remains in the state door locked If the operation fails the door remains unlocked In general you may say that the state machine stands e
196. l 11 3 DEVELOPMENT PROCESS 215 AD Umgebung TSI AD Umgebung B Benutzermanage ES initializef Ei State Mad EEE m Figure 11 9 Usability of the tree view Furthermore sequence diagrams can be generated out of the simula tion of the model verifier User support There is some support in establishing and maintaining the software process When starting a new project a wizard enables you to create an appropriate workspace with some packages already in tegrated Once a new project is created there is no automatic guide But nevertheless Telelogic lays a strong emphasize on sticking to their design guidelines described in their on line help In general you are not restricted to start modeling with low level objects and state charts diagrams Of course there are some process dependencies due to the fact that some components of later processes require elements of the former ones e g parts which are instances only can be created when classes are defined Furthermore one could never test a state chart di agram using signals that are not defined and when no architecture diagram shows how the signal flow is like Consistency ensurance mechanisms e Syntactic consistency Some very useful functions are provided in order to maintain consistency between the model tree and the views E g if you change a name in the tree all diagrams are changed consistently On the other hand if you change a graph ical e
197. l Development 34 Concusion les Model Based Development Bibliography ax 42 2 82 2a ua ea The Tools Tool ARTiSAN RealTime Studio 5 1 General Aspects sa re 5 11 Functionalities 5 1 2 Development phases 235 6x5 5 13 Documentation 5 14 Usability sehe CE ne 5 2 Modeling the system vx 5 2 1 Available Description Techniques 5 22 Applied Description Techniques 5 2 3 Complexity of description 5 2 4 Modeling Interaction 5 3 Development Process oo 242432322 5 3 1 Applied Process 8 sm a 5 3 2 Process Support se x uu god pne exa 5 8 3 Applied quality management 5 3 4 Applied Target Plattform 5 3 5 Incremental Development 5 4 Conclusion 2 22 2222 5 5 Model of the Controller 5 5 1 Description of the structure 552 Description of the functionality Ascet SD 6 1 General Aspects s 8 Sake eed er 6 2 Modelling the System em ES 6 2 1 Available Description Techniques 6 2 2 Applied Description Techniques CONTENTS CONTENTS 6 2 3 6 2 4 Complexity of Description 408 eer s usa Modelling Interaction 222 2 22 2 23 2 2 6 3 Development Process es 2 2 OS ee at AC 6 3 1 6 3 2 6 3 3 6 3 4 6 3 5 Applied Process 2o acs wx Ry UR AS nase Applied Process Support ls Applied Quality Management Applied Target Platform 4 o
198. l description techniques like block diagrams and state machines These techniques allow a very flexible and exact textual or graphic modelling In addition the tool supports the hierarchical capsulation and the reuse of components that can be exported and imported in other models The created model and its components can be tested in a so called Offline Experiment There the model s behavior can be checked and displayed depending on the inputs stimulated with various signal types sinus pulse constant etc The test cases represented by en vironments with predetermined input parameters can be saved and reloaded and therefore a kind of test case management is supported It is not only possible to simulate the system but also to test the sys tem in real time and under real conditions on the experimental plat form with the Online Experiment The validation of the model is done by intense testing using the Of fline or Online Experiment On the other hand the verification pro cess is not explicitly supported But due to the automatic code genera tion the verification can be assumed to be done automatically as well 73 74 CHAPTER 6 ASCET SD With the code generator the user has the possibility to convert the model to C code for several market relevant target platforms The generated code is additionally optimised to achieve a maximum of performance and precision Last but not least ASCET SD offers the possibility to
199. l layer The physical connectors including the can bus has been modeled in the physical layer Each connector class handles in and outcoming signals for a single connector 5 5 2 Description of the functionality As shown in the class diagram in figure 5 4 the model is separated into three layers Each layer is described in this section Figure 5 5 shows exem plary classes for each layer Controller Classes The whole functionality which should be offered by the system has been divided into the three main tasks user management seat adjustment and door controlling Each of these tasks is implemented by one controller class Atomic use cases of one task are mapped to single methods of the cor responding controller The controllers communicate exclusively with the model layer Single use cases are invoked indirectly by signals forwarded through the physical and the model layer Model Classes Each class in the model layer represents a separate device mentioned in the case study Besides the relatively simple button classes which mainly 67 5 5 MODEL OF THE CONTROLLER Qabessayp tar c TOWNE 1331 u1 EI OE ZOO zz 265 BL oou 2234 4265 Em ua 25 Dijon 100g p een aD penis zo HLNAZ UL LC HLN3Z Cate zanan eoa EELEE E Igori 331 6131235 One in METi EEEE 0 zb espent E WELTEN jad L Eh ER Jar 131 Ed 11 2ur beg 1227 M AMOI Figure 5 2 System Architecture Diagram Owasso L noua
200. l of the Controller SSD s are similar to class diagrams and define the entities signatures and the direction and type of messages which are exchanged be tween them They consist of components ports and channels The main concept of the communication between components is the port channel architecture Every component can have input and output ports that can be connected via channels Messages are sent over channels which connect ports belonging to differ ent components Ports can have various attributes The incom ing values can be flushed kept or sent immediately through the following channel Components can also have local variables Those variables must be well typed like ports and channels In the requirement analysis man can use socalled extended event traces EETs see Section 7 4 Model of the Controller message sequence charts MSC or sequence diagrams Those notations can help defining the components and the type of messages that are exchanged between the different components and also be tween the system and the environment In an EET every compo nent has its timeline and messages can be drawn between them EET s are also generated by the AUTOFOCUS testing environ ment from the test data to visualize the flow of messages They cannot be used to define the system model but they are useful 7 2 MODELING THE SYTEM 103 for the requirements elicitation because they support the devel oper in the analysis of complex
201. l returns the same results if some thing was changed in the system structure This way testing can be automated The test vector files can easily be viewed and altered in a text editor Other test tools could be easily integrated The test driver genera tion can be a good assistance here A driver in C could be written to integrate such a third party tool Certification The code generator is not certified by an independent author ity Requirements tracing A way of requirement tracing might be to create test vectors in the analysis phase These vectors can then be used during the development process to verify the system But this process is not 112 CHAPTER 7 AUTOFOCUS particulary supported by AUTOFOCUS There are no interfaces to requirements engineering tools 7 3 4 Applied Target Platform Target code generation No code optimization for specific micro controllers is supported Supported targets From the models created with the AUTOFOCUS tool Ada and ANSI C code can be generated This code can be run on various platforms Where C or Ada code may be compiled and run Using cross compilers the ANSI C code may be adjusted to run on almost any system Java code may also be extracted from the model But this is not officially supported since this is not a key feature and the code is not very good Code size The C code size of our model is about 31 kB This is equally to about 6531 lines of code This size was measured on a 32 bit C
202. lab Stateflow with the help of subcomponents i e subcharts and several graphical functions for the functionality The centralized door locking is split into two substates The state zu for all doors being locked and the opposite state offen for all doors being open The state zu includes the functionality for the case that the doors are locked and shall be opened while the state offen ensures the locking of the doors In both states it is necessary to check if there is enough battery voltage to empower the specified motors to do their duty At the end of each successful action opening respectively closing the bars of the doors the corresponding state sends a signal for blinking The seat adjustment too is made out of two different components one for the manual seat adjustment the state manuell and one for the seat ad justment via the user management the state benutzermanagement In both cases the seat can be adjusted in five axes back horizontal the distance from the seat to the steering wheel seat casing and the front as well as the back height of the seat These axes can be moved in two direc tions e g you can lift or lower the front of the seat When a button for one of these axes is pushed the manual seat adjustment reacts and adjusts the seat just as long as the button stays pressed assuming there is enough bat tery voltage for the relevant motors and the car s doors are open It is the user management s turn when either
203. lement in a view either a new element is created in the tree or the element in the tree is modified depending on the modi fied element But sometimes these helpful functions also cause some trouble One problem we often had was that it is possi ble to define elements with the same name and type within the 216 CHAPTER 11 TELELOGIC TAU same class but different reference As elements are sometimes created automatically when using them in a diagram there were elements with the same name but different references Then we had serious consistency problems When deleting one of the re dundant elements the correct references have to be made but now to the remaining element While the user edits the project Telelogic Tau permanently veri fies the users actions and marks errors The tool checks the input concerning syntactic correctness Found errors are highlighted Syntax Error A Figure 11 10 Syntax Error as can be seen in Figure 11 10 If you try to create an object of an undefined class Tau recognizes that and underlines the not existing class reference as seen in Figure 11 11 Part Klasse Figure 11 11 Class not defined Error In order to detect all syntax and rudimentary semantic errors you can press the autocheck button Also a partial check is pos sible Then only the parts lying under the actual node shown in the tree view are examined Tau lists the errors and warnings in a message window that can be seen in F
204. level debugging used in Rhapsody in MicroC Fi nally the engineer can define so called test vectors simple text files in which a row of button presses slider changes etc is defined at a certain time in his panels which can be replayed automatically later This especially helps when testing the same test case several times The graphical back animation enables testing even on the target pro cessor Development phases Rhapsody in MicroC supports the user in all devel opment phases During the requirement analysis the engineer has the possibility to draw use case diagrams and sequence diagrams An example of a use case diagram is depicted in Fig 9 1 for a typical sequence diagram see Fig 9 2 Use case diagrams serve to structure the different use cases of the system and sequence diagrams to define the interaction between the subcomponents itselves and the environment during the execution of a single use case During the system design the developer can use activity charts to describe the structure of the system Furthermore Rhapsody offers automatic code generation from the design model Nevertheless the developer has the possibility to integrate self written C code to spec ify the behavior of single components of the model 9 1 GENERAL ASPECTS 157 BENUTZER TUERSTEUERGERAET MOTOR ACHSE ACHSE ACHSE SSENSOR STOPPT ACHSE Figure 9 2 Example sequence diagram The implementation phase is totally hidden from the develop
205. li braries available These are two packages that can be found at the bot tom of the tree view The first one profile contains some controller components and the classes for the graphical components of the tool like classes states all kinds of diagrams The other library prede fined packages contains basic types like boolean variables strings arrays Development history The full history of modeling is stored until the first step of the current session You can always go back as far as you want However the undo stack can be deleted manually If you go back and do some changes you cannot go forward any more It is not possible to set recovery states where you can jump back automatically 113 3 Applied Quality Management In order to validate the model with respect to the specification we started the model verifier which lets you simulate the model You can monitor variables in a message window Furthermore a sequence diagram of the whole model is generated showing the interaction and the values that are sent We compared these data with the specification we got and changed the model when necessary 218 CHAPTER 11 TELELOGIC TAU Host Simulation Support The host simulation is done by the model ver ifier which serves as a verifier and simulator at the same time Target Simulation Support The tool itself did not provide simulation on a target platform Nevertheless the whole model is saved as an XML file format and not
206. like manner Examples are Se quence Diagrams in Rhapsody in MicroC and Rational Rose RT Data Description describing the data types used to define messages sig nals or variables Examples are Class Diagrams in Telelogic Tau and Trice The first three are generally defined using a graphical description includ ing complex textual expression e g for the description of transitions or events interactions the latter either graphically or textually Note that there are two different forms of structural descriptions typi cally found in embedded systems Component Structure describing concurrently active networks of distributed components loosely synchronized by message communication gen erally each component represent a heavy weight process Examples are Architecture Diagrams in Tau Capsule Diagrams in Rose RT and Trice or System Structure Diagrams in AutoFOCUs Data Flow describing units of computation which are activated sequen tially tightly synchronized by the data flow between them generally Note that influenced by the UML class or object diagrams are partially used to describe structural aspects however these are generally enhanced by some form of architecture dia grams 28 CHAPTER 3 RESULT SUMMARY each block represents a light weigh task Examples are Block Dia grams in ASCET SD or MATLAB Simulink Furthermore some tools offer additional description techniques Scheduling and Real Time Aspects us
207. lization of the case study we have been using Stateflow s state transition diagram and only for testing Simulink s block diagrams Modeled aspects The state transition diagrams as well as the block dia grams can be used for modeling the system s structure and its be havior though we used for this only state transition diagrams as we estimated this to be easier Examples for such models of structure and behavior can be found throughout the section about our model s components 8 5 2 The interaction between our model and the envi ronment was realized by a block diagram as can be seen in Figure 8 3 where a simple model of the centralized door locking and its output to the environment is shown Char Figure 8 3 Interaction of model and environment Notations suitable In our opinion the provided notations are suitable for modeling the case study and also for similar systems Clearness Within the state transition diagrams there is a conflict between readability and clearness of a model Either you improve readability by reducing the number of elements especially transitions in one view and structure your model in deeper hierarchies or you sup port the clearness by avoiding deep hierarchies which require a lot of browsing and searching for the right next element The notational support lead to a clearly structured model with deep hierarchies Unused notations We used all of the supported notations Missing notations
208. ll be trans mitted to the seat adjustment In this case the seat adjustment cannot start its work To store the current seat position has absolute priority over reading a stored position A signal triggered by the user himself has priority over a signal triggered by the system as a CAN message The entry logic guarantees also that always the last incoming signal is considered If the seat adjustment is required but no seat position is saved in the store it will not start Additionally to the position values two other signals are sent namely a start signal and a signal indicat ing if the trigger for the whole operation was the radio transmitter save the position read a position entry logic current set position get position position transmitter read position Figure 6 18 Functionality of the user management In addition to these signals the seat adjustment gets the real current values of the seat position to compare with the stored values It also receives the input signals from the manual seat calibration If the 6 5 MODEL OF THE CONTROLLER 99 seat calibration gets as start signal a rising edge from the user man agement a variable will be set The seat adjustment works while this variable is set To stop the working seat adjustment this variable must be reset Now there are five compare elements one for each seat axis As long as the desired seat position received by the user manage ment i
209. lly embedded software systems are mov ing from monolithic single functionality programs to distributed in teractive multi functionality networks a central aspect of such a model is treatment of interaction and communication as well as time related aspects Furthermore a model must support specific aspects needed for the application domain for the domain of embedded real time sys tems e g notions like messages or signals task schedule controller bus By supporting domain and application specific modeling el ements more information about the system under development is represented in the model leading to stronger analysis and genera tion techniques e g in the domain of embedded systems checking the wort case time bounds of a task or generating a bus schedule from the communication description of a component model Abstract Models A model should contain only those aspects needed to support the development phase they are applied for e g modeling the interaction between components by messages rather then method calls to the bus driver or the operating system By abstraction a model reduce the complexity of description as much as possible as well as the possibility to produce faulty descriptions e g ensuring type cor rectness between communication ports rather than using byte block messages on the level of bus communication Furthermore an ab stract model also supports descriptions of the system under develop ment in ea
210. lopment process looks like with a focus on the design phase Finally we sketch what should be expected from future tools by giving a vision of model based development of embedded software 14 Acknowledgments The assessment of the state of the art in CASE tools for embedded systems would not have been possible without access to a representative collection of those tools We are therefore especially thankful for the personal com mitment of the vendors and distributors through their representatives not only in supplying us with free trial versions but also in supplying the stu dents with an introductory course as well as valuable feedback during the construction of the models e Andreas Korff from Artisan Software for ARTiSAN RealTime Studio 12 CHAPTER 1 INTRODUCTION Ulrich Freund from ETAS GmbH amp Co KG for ASCET SD Validas AG for AutoFOCUS support Andreas Goser from The MathWorks Inc for MATLAB StateFlow Rainer Hochecker and Hans Windpassinger from Rational for Rose RealTime Peter Schedl and Carsten Sbick from Berner amp Mattner for Rhapsody in MicroC Wolfgang Sonntag from Telelogic Inc for Telelogic Tau G2 Klaus Birken from Protos Software GmbH for Trice Tool Part I Preface 13 Chapter 2 Assessing the Tools Bernhard Schatz Tobias Hain Wolfgang Prenninger Martin Rappl Jan Romberg Oscar Slotosch Martin Strecker Alexander Wisspeintner While all of the tools discussed in the sections of the second
211. ly enjoyed our work with ARTISAN RT Studio and wish ARTiSAN Software Tools Inc good speed 5 5 Model of the Controller This chapter gives a short overview of the system modeled during the case study 66 CHAPTER 5 TOOL ARTISAN REALTIME STUDIO 5 5 1 Description of the structure Figure 5 2 shows the System Architecture Diagram which visualizes the communication between the controller to be build and the interface devices based on the case study Especially the flow of the different signals has been described seriously This diagram is the base of the structure for the system components After finishing the System Architecture Diagram we have created vari ous Sequence Diagramms see Figure 5 3 These diagrams were developed in a round trip engeneering process from representations of textual use case descriptions up to detailed communication protocols between subsystems which directly became the classes of the object model The whole class model as shown in figure 5 4 is structured in three layers The control layer is composed of three classes the UMController User Management SAController Seat Adjustment and DoorController Door These controllers assume the functionality described by the use case model For every kind of interface device a representation class has been in cluded in the model layer Each class offers an logical view to the corre sponding interface device to link together the control layer and the physi ca
212. mited range therefore On the other hand this independence led e g to changing the state chart diagram of each of the five axes separately Modular design As we developed incrementally we integrated a modu lar structure later in the process But Tau also has all characteristics enabling modular developing For example Tau offers packages Restructuring We extensively tested the restructuring capabilities of Tau when breaking down the system from one into three basic classes It is no problem dragging around whole state chart diagrams and distributing them among the new classes All nodes and local vari ables are transferred or copied automatically to the class If classes are structured into different packages you have to include the packages in order to use their content in other packages 11 4 Conclusion The tool was in a testing phase when this seminar started and has been released meanwhile We used a preliminary version of the tool Because of some bugs in this preliminary version it was not always possible to use the most elegant solutions some components couldn t be used or we were not capable to use it We want to evaluate Tau on the basis of three major aspects documen tation usability and modeling Due to the fact that UML2 0 is not released yet we had some trouble in finding appropriate information on modeling techniques that were not part of UML1 x Furthermore none of us had experience with SDL which con side
213. ms In the simulation environ ment provided by Rational Rose RT we finded the difference between the expected behavior specified by the state machine and the observed behav ior of the system and modified opitimized it 10 3 2 Applied Process Support Rose RealTime can be used through all phases of the software develop ment lifecycle from initial requirements analysis through design imple mentation test and final deployment It provides a single interface for model based development that integrates with other tools required dur ing the different phases of development For example we work directly through Rose RealTime to generate and compile the code that implements 10 3 DEVELOPMENT PROCESS 191 the model The actual compilation is performed behind the scenes by a compiler linker outside of the toolset Using Rose RealTime we work at a higher level of abstraction specify ing behavior in state diagrams At a more detailed level the process of creating an executable model in Rose RealTime can be summarized as follows Use the use case modeling elements and use case diagram to develop a detailed semi formal understanding of the problem The use case ele ments can be associated with design elements as the design model evolves to maintain traceability Create capsules protocols classes use class diagrams capsule struc ture diagrams and capsule state diagrams to develop the structure and behavior of the model Add detailed impl
214. n Support In Rhapsody it s possible to simulate the model on the host you developed it The simulation is based on the code which is generated for the Windows host target For providing a user interface to the modelled system RiMC has a tool called panel builder which allows you to create panels that shows the in output of the system Panels include buttons scrollbars slider control lamps and many other ways to show and also influence a simulation of the cre ated model The user can also add some visualizations by creating effects with hidden or shown parts in a picture which are bound to shared vari ables RiMC offers the user to build their individual panels A char acteristically panel we used in the case study is shown in figure 9 8 Furthermore RiMC is able to create panels by itself But these panels are not very useful because the tool just lists all used shared variables and creates bindings to the so called lamp interactors 168 CHAPTER 9 RHAPSODY IN MICROC HOMO ST ook Achse_v Q Q ht E D Sf L2 E w D S a Pos 2 Pos Tuerschlo Q Q close open o 90 t griff sensor ERROR El gl a Bl 9 Ja al BI Bl la S o E m ale I IO OL Achse_w SOl L steiler flacher Bl al l B Figure 9 8 Simulation Case Study The GBA animation colors the states in whi
215. n be used to simplify a model The state transition diagrams realize complex re active systems and with Simulink s block diagrams one can imple ment dynamic systems There is a difference between Stateflow charts and Simulink block diagrams considering data flow in Stateflow the events are broadcasted across the whole model whereas in Simulink data is transferred from one block to another only along existing con nections This means that in Simulink interfaces are explicitly speci fied but in Stateflow this is not possible Interaction cannot be mod eled in advance because of the missing sequence diagrams 8 2 2 Af ter the model is finished the resulting interaction can be displayed with scopes Type of notation As already mentioned above the Stateflow notation con sists of graphical parts like states and transitions and non graphical one whereas Simulink makes use of graphical notations There is the possibility to parameterize each element within a dialog Hierarchy The provided notations can be organized in hierarchies of ar bitrary depth so one can build models top down or bottom up The hierarchies in Stateflow state and function hierarchy can be browsed either within the modeling view or using Stateflow s explorer In Simulink a hierarchy can be achieved by using subsystems which one can view with the help of the context menu 8 2 MODELING THE SYSTEM 127 8 2 2 Applied Description Techniques Applied notations In our rea
216. n the case study and what would have been modeled using these notations e g behavior structure interfaces interaction 2 2 3 Complexity of Description This section provides an estimation of the size of the built model Only the part of the specification used for executing the model simulation code generation is considered e g sequence diagrams and use case diagrams are not considered Since tools generally use graph like diagrams to model a system a diagram based metric for the complexitiy of the model is used Basis for the metric are the notions view e g diagrams drawn node e g block component class state used in a diagram edge e g association channel transition used in a diagram visible annotation text visible in the diagrams and invisible annotation text hidden in dialog boxes Views How many views are used in the whole model Nodes How many nodes are used in the whole model How many nodes are user per view average and maximum Edges How many edges are used in the whole model How many edges are user per view average and maximum Visible annotations Size of the visible annotations per view maximum measured in characters Invisible annotations Size of the invisible annotations per view maxi mum measured in characters 18 CHAPTER 2 ASSESSING THE TOOLS 2 2 4 Operational Model Obviously the choice of the operational model used to interpret the di agrams influences the complexity
217. n the user tries to drag and drop a new parameter into it 6 2 Modelling the System 6 2 1 Available Description Techniques Supported notations The modelling language of ASCET SD supports several constructs to struc ture the model and to describe its behavior Models are structured by projects modules classes and state machines Project The project is the main construct containing everything else It is a collection of modules and serves to configure the interaction with the underlying real time operating system like ERCOS FK 1 that con trols the execution of the various algorithms and computations This means that the operating system s task scheduling see Fig 6 2 page TEC 61508 certification Functional Safety of Electrical Electronic and Programmable Electronic Safety Related Systems 76 CHAPTER 6 ASCET SD 76 can be defined in the project The processes listed in the tasks are executed on activation of the task and execute the processes associ ated in the modules Setting the periods of the tasks to a little time interval provides the possibility to simulate the system in real time Furthermore the code generator can be launched from the project Project hun Kalle LEER ee oe m e Figure 6 2 Example of a project and its scheduling Modules Modules are the next structural entity They can contain classes and state machines A module is designed to encapsule an autonomous control unit funct
218. n version configuration management but one can include third party tools like Rational ClearCase Development phases Stateflow can be used during the following devel opment steps e design you design your model by fetching the necessary com ponents from the toolbar and connecting them with transitions e implementation the step of implementation is identically to the automatic code generation from your model e test you can simulate your model in Simulink Stateflow with different sets of input values 123 124 CHAPTER 8 MATLAB STATEFLOW The Stateflow documentation describes the steps design and imple mentation as modelling Documentation We have not been provided with a printed manual and had to get along with the online help MATLAB s online help is real ized by a modified HTML browser Thus the user has the possibility to create bookmarks for his favorite help topics The online help also offers a really useful search mechanism and an index which doesn t include very detailed information The single items in the help sys tem are sometimes a bit short and unprecise so that the search for the wanted information can take longer than expected In Simulink there is also the possibility to directly view the description of a component by using the component s context menu In conclusion the documen tation is adequate Usability The tools are both quite easy to use due to the click and drag approach ie you can eas
219. nal Conference IEEE Computer Socienty 2003 SPHPO2 Bernhard Schatz Alexander Pretschner Franz Huber and Jan Philipps Model based Development of Embedded Sys tems Technical Report TUMI 0402 Fakult t f r Informatik TU M nchen 2002 Part II The Tools 49 Chapter 5 Tool ARTiSAN RealTime Studio Christoph Angerer Martin Glaser and Christian Merenda 5 1 General Aspects ARTISAN RT Studio is a development platform for embedded systems It is mainly based upon the UML 1 4 Unified Modeling Language extended by some enhanced notation techniques This paper evaluates capabilities as well as possible weaknesses of ARTISAN RT Studio Basis for this eval uation was a shortended version of the case study Das T rsteuerger t eine Beispielspezifikation which can be found at http www iese fhg de pdf files iese 002 02 pdf e Section 1 gives a short overview over ARTISAN RT Studio e Section 2 describes the features of ARTISAN RT Studio for modelling systems as well as as which features we used including some experi ences during the case study e Section 3 deals with the subject development process especially how ARTISAN RT Studio supports managing development e Finally after a conclusion in Section 4 we introduce our model of the door controller in section 5 5 1 1 Functionalities ARTiSAN RT Studio supports several modeling diagrams The standard UML diagrams these are Activity Diagram Class Diagram
220. nce basically structure be havior and data descriptions are sufficient to describe an executable model of the system all sets of description techniques offered by the tools were considered to be sufficient If no interaction descriptions by event based forms like sequence diagrams were available e g Matlab Simulink those were found missing Furthermore hierarchy within graphical description techniques e g state sub state was considered essential in all tools e g Telelogic Tau The use of graphical description techniques combined with the possi bility of abstraction hierarchical structuring was considered to greatly im prove the clearness of the model Generally clearness of the model was interpreted as being related to the simplicity of the model resulting in reducing the number of connections between modeling elements espe cially transitions non surprisingly this reduced complexity per view is achieved at the cost of deeper hierarchies 3 2 3 Complexity of Description The complexity of descriptions is influenced by factors like Hierarchy support reducing the complexity by hierarchically structured descriptions e g state sub state and corresponding mechanisms e g group transitions for a hierarchical state Computational model affecting the resulting complexity of the annota tions e g parallel reception of signals vs accepting only one method call at a time as well as the number of transitions Furtherm
221. ncluding test coverage metrics 3 3 DEVELOPMENT PROCESS 39 is not provided by the majority of tools static analysis techniques are miss ing almost entirely also see Section 3 3 2 Since all these quality assurance mechanisms are required in standards like IEC 61508 it is not surprising that only very few tools have been certified so far 3 3 4 Applied Target Platform Since code was not deployed in this case study this section gives only a short overview about tool features for target code generation and deploy ment Target code generation and supported targets All of the reviewed tools support the generation of code that can in principle be run both on the host and the development target The C and C languages are supported by all tools in addition Rational Rose RT supports Java code generation Usually running the code on a target would require adaptations like adaption to the language subset supported by the target compiler or appropriate operating system calls and configura tion As a notable exception ASCET SD Matlab Simulink and Trice support a range of embedded targets and rapid prototyping environ ments by compiler and OS specific adaptations of the generated code Code size The target code size binaries tended to be in the 8 80kByte range while memory consumption was up to 800kByte for the run ning model on the host These figures are preliminary results as the focus of the evaluation was not on code generati
222. nction poscheck_sitz sitz_vome idle v ix et sta vot C Hier offend O Joount 2 zo M Se N Im _ count count 1 PS count count 1 I x D gi va ib Imotor sitz vome HEBEN Iposcheck sitz vome ANSCHLAG_OBEN siztasto etz vorne HEBEN pe M tuer offen RM EX Em otztaste_eitz vorna SENKEN ES a X 1 Ne En N Ei Ss SSS M Hiposcheck sitz voms ANSCHLAG UNTEN Motus az vomeg Ausl P N un ofi B Iposcheck sitz voma ANSCHLAG OBEN js M Sas E ERR a B H Em x limolor sitz vorne SENKEN x sitztaste_sitz_vome AuS motor_ SS poc poscheck_sitz_vorne ANSCHLAG_UNTEN IP err rr rrr rrr rerrrrrrr rrr errr reer reer reer rere rere tad Figure 8 11 State sitz_vorne function result sitztaste_sitz_vorne in_SITZ_V 1 0 result SENKEN result AUS in_SITZ_V 1 0 result HEBEN Figure 8 12 Function sitztaste_sitz_vorne _vorne val which is analyzing whether the lower limit of the resis tance value is passed or the upper limit is exceeded so that no more seat adjustment is possible If at least one of these conditions occurs the active motors of the seat adjustment are switched off Afterwards the semaphore is decreased by one as the result of leaving the critical region and the transition back to the initial state idle_v is taken Additionaly there are the functions spannung_aus which switches off all the motors of the seat adjustment at once a
223. nd 7 kB on a HC12 microcontroller target This accords approximately 9000 lines of C code On the one hand RiMC generates very small code on the other hand the tool comes off well concerning the readability of code Readability of code The good readability of generated code is a strength of RiMC The structure of code is identical to the structure of the state charts This means that the code can be divided into several parts Every part stands for one state chart Due to this fact tracing between the code and the model is enabled If the model is commented very well the easy understanding of the code is backed But the feature that allows someone to navigate from the code to the equivalent part 170 CHAPTER 9 RHAPSODY IN MICROC of model by mouse click is missing Nevertheless integrating the gen erated code into another C code is feasible In the event of correctness of the modelled project there shouldn t occur any conflicts To check whether the model is in proper style there is a feature called Mod elchecker 9 3 5 Incremental Development Reuse In the case study only the parts which were not affected by the changes of the step from two to five axes could be reused Especially the door close open statecharts could be used again The open mechanism in the keys had to be fitted to the new created seat control charts including the handling of the five axes The user man agement had to be built completely new because the request
224. nd batt_low_sitz which tests whether the battery voltage is sufficient for seat adjustment Only if the voltage has a value of at least 10 0 V adjustment of the seat is possible 144 CHAPTER 8 MATLAB STATEFLOW User Management The main model of the user management starts with the state verteiler Here it is decided which of the posible actions call ing a saved position via CAN bus calling a saved position by the user management buttons or saving a position into one of the four available memories The verteiler makes different checks within the functions mgmt_can mgmt_taste and mgmt_speichern and decides which state must be activated benutzermanagement SS fertige_motoren 10 verteiler E gt Imgrm_tastei fferige motoren Q Sitztaster Ino 0 tasten_check m Es debug_speichem speicherplatz Ss mamt_speichern ES SN pom speichem ER ES 273 a ya pa ee debug speichern speicherplatz can bus Figure 8 13 Overview of the complete user management State can bus If a stored position from one of the memories should be recalled control flow passes first to the state can check where it is tested whether the memory that should be accessed has already been used for saving a position and whether there is enough battery voltage to perform the adjustment In case that these conditions are met the transition to can bus is taken other wise state verteiler is activated again as no
225. nents in the system library are contained The manual is available in German and English and many screenshots and detailed directives facilitate the understanding The information available online is much more general but allows to get a quick and short overview There are listed the main functionali ties the highlights and applications Moreover some screenshots and comments provide an insight into the development environment Altogether the offer of documentation about the tool is good Usability ASCET SD features good usability Its graphical user interface allows to build the model almost entirely by drag and drop compo nents and by drawing logical circuits and connections To configure the components e g set their data types or values the tool provides dialog boxes where the information can be easily entered or selected The toolbar or popup menus are well structured and contain all im portant functions That way they enable a quick and effective work ing Visual aids like color icons and hierarchical collection of compo nents raise additionally the clearness and readability of the model The usability is adversely affected by a slow display caused by many components and by the zoom s absence Moreover the display does not update every change and the popup menus appear far away from the position clicked The windows handling could be realised better sometimes For example the oscilloscope does not remain on the top level whe
226. nerator of Trice generates ANSI C and ANSI C source code which can be integrated in software projects easily However Trice supports some special targets and tools directly which makes the usage of Trice for these targets and with these tools even more sim ple Depending on the chosen target additional support is given for certain third party tools Microsoft Visual Studio Keil Vision2 IDE Watcom Compiler GNU C Compiler Unix make which cooper ate with Trice seamlessly The properties of the target determine the target language for the code generator E g on small embedded sys tems efficient C code must be generated in order to take into account the limited resources of these systems Therefore Trice distinguishes between targets with C generation and those with C generation For the following operating systems and platforms the runtime sys tem protos Virtual Machine and ProjectIemplates are available for a quick start but we have only used the Windows 2000 NT plattform for our development process e Windows 2000 NT This is also the development platform where Trice itself is running The generated code can be executed on the development host directly This is used primarily in early phases of development Later on this target platform is well suited for event driven non real time software e g protocol stacks e ONX We haven t used this plattform Windows 2000 NT with LPRI Win We haven t used this plat tform
227. ning messages are shown in a separate display The mechanism allows to click on the error display and it jumps automatically to the error in the model Unfor tunately error messages are often very cryptical and therefore some times not really useful Error messages point to serious faults in the specification that lead the code generation process to be terminated Warnings point to less serious faults ASAM is an interface description for hardware 86 CHAPTER 6 ASCET SD Furthermore the tool contains a mechanism to check the unambigu ousness of identifiers It also can do automatic typecasting between the arithmetic types if necessary Component library ASCET SD contains a predefined component library From this component pool we used only the rising edge Further more new components can be generated and stored as part of your own library Development history We recorded the development history manually be cause we could not find any support mechanism Apparently there exists a tool called KM Tool Box that allows to manage development states 6 3 3 Applied Quality Management Throughout all supported development phases we used the Offline Exper iment to validate the model and to check if the functionality of the model complies with the specification On the base of this test environment we made various tests to check the correctness and completeness of the model But to verify the generated code especially the tool does n
228. nlock the doors To come back to the exception the specification says if there is a trial to start the engine you have to wait one second before checking again the voltage level of the locking motors But it wasn t clear to us when exactly this sec ond should take place Either you wait directly after the starting trial or there is the starting trial successful or not and then you have to wait this one second before checking the battery Our decision was to take the sec ond possibility as it sounds more reasonable to us In the section about the behaviour for locking the doors there was the same contradictory description of the values needed by the commands ZV _SCHL_A ZV_SCHL_L and ZV_SCHL_R as in the section about unlocking the doors According to our upper choice we now send the value 01 binary to bar the doors Again in the battery checking case the command is ZV_SCHL_L and not ZV_SCHL_R If there are sensor values which don t fit together i e opening and closing at the same time it is specified that the doors shall be opened This is re alised with the signal ZV_SCHL_L 10 binary and not as given in the first version ZV_SCHL_R 01 binary 154 CHAPTER 8 MATLAB STATEFLOW Chapter 9 Rhapsody in MicroC Bastian Best Julian Broy Gerrit Hanselmann and Peggy Sekatzek 9 1 Rhapsody in MicroC is a graphical model based development envi ronment designed specifically to enable users to produce software for micro controllers
229. nnen ist immer m glich unabh ngig davon ob die Zentralverriegelung offen oder geschlossen ist mechanisches ffnen Wird eine Fahrzeugt r von innen ge ffnet werden alle T ren entriegelt In Abschnitt 5 4 findet sich die ausf hrliche Beschreibung der T rschlo steuerung 3 Komponentenbeschreibung 3 1 Position im Fahrzeug Je ein TSG wird in der Fahrer und Beifahrer T r eingebaut siehe Abbildung 2 Abbildung 3 zeigt schematisch die Anordnung der Bedienelemente die dem TSG zugeordnet sind Abbildung 2 Position des TSG im Fahrzeug Sitztaster Sitztaster I Beifahrert r Abbildung 3 Schematische Darstellung der Anordnung der Bedienelemente Benutzer management Fahrert r 7 3 2 Schnittstellen Das TSG wird ber drei Steckleisten mit seiner Umgebung verbunden e Stecker S1 24 polige Steckerleiste ber diesen Stecker werden alle Sensoren und Aktoren innerhalb der T r angeschlossen e Stecker S2 49 polige Steckerleiste ber diesen Stecker werden alle Sensoren und Aktoren au erhalb der T r d h im Fahrzeuginnenraum z B Sitztaster im Fahrzeugrahmen und in der zugeh rigen Fondt r angeschlossen e Stecker S3 8 polige Steckerleiste ber diesen Stecker erfolgt die Stromversorgung sowie die Ankopplung an den Innenraumbus CAN Bus Nachfolgend werden die einzelnen Schnittstellen detailliert beschrieben 3 2 1 Stecker S1 T relemente Die Kontaktierung ist d
230. ns 1 Defining and refining the system structure by introducing sub components using structural diagrams 2 Adding behavior to the sub components using state based di agrams or data flow diagrams 3 Validating and refining the behavior of sub components using simulation Integration Validation In this phase the different components were inte grated into one system generally due to the component model sup ported by the tools this requires no additional steps and validated by simulation Generally Step 1 step was performed by all tool applica tions 3 3 DEVELOPMENT PROCESS 35 1 Generating simulations of the complete system either generat ing scenario based descriptions of simulation runs or using sim ulation interfaces 2 Comparing the simulation results with the scenario based de scriptions Several of these steps are more explicit in certain processes depending on the available and applied process support as explained in the following Subsection 3 3 2 Applied Process Support Development Operations Simple development operations e g cut and past of elements within one diagram are generally supported by all tools Depending on the status of the tool academic prototype vs wide spread product new release vs es tablished product the stability and functionality of those operations differ Complex development operations i e supporting complex stereotypic or application domain specific operations
231. nsure cer tain coverage criteria on the model or the implementation Only few tools have support for deployment of the code including the definition of tasks and their scheduling on a target processor More com mon is the generation of code targeting special processors for deploying the code on the hardware Furthermore the support for deploying code to multi processor systems is rudimentary 3 13 Documentation The documentation of the tools generally consists of a user manual inte grated help features a tutorial and examples All tools have been ranged 26 CHAPTER 3 RESULT SUMMARY from satisfactory to very good The most cited deficits in the documen tation were their incompleteness i e some features of the tools are not included in the documentation 3 1 4 Usability Obviously the usability of a tool is coupled with the complexity of the offered functionality A view based tool with little ensured inter view consistency is more flexible concerning applicable user actions and thus is considered sufficiently usable when supporting standard functionality like creating a state and introducing a transition On the other side a more model based tool using a consistent model or repository for all views is much more restricting possible user interactions and thus requires a high level of support e g feedback why an action is not applicable to be con sidered sufficiently usable However some general criteria can be applied reg
232. ntfernung Sitz Lenkrad Lehnenwinkel Schalung Sitzfl che vorne Sitzfl che hinten o Ist die Batteriespannung BATT zu Beginn der Sitzverstellung kleiner als 10 V so werden die Sitze nicht bewegt Statt dessen wird die Meldung B LOW SITZ 1 generiert e Fall 2 Auswahl einer Einstellung ber Funksender o In diesem Fall soll die gew nschte Sitzposition so schnell wie m glich eingenommen werden Dazu werden alle Sitzmotoren gleichzeitig angesteuert o Ist die Batteriespannung BATT zu Beginn der Sitzverstellung kleiner als 10 V so werden die Sitze nicht bewegt Statt dessen wird die Meldung B LOW SITZ 1 generiert Initialisierung Keine Aktion 5 3 Benutzermanagement Eing nge e Konfiguration Benutzermanagement CONFIG B MGMT e Position des dem TSG zugeordneten Sitzes S2 SPOS HOR S2 SPOS H S2 SPOS V S2 SPOS S SZ SPOS W e Tasten des Benutzermanagements SI MGMT 1 SI MGMT 2 SI MGMT 3 SI MGMT 4 SI MGMT SET e CAN Botschaften zum Abrufen einer Speicherposition Fahrer TSG nur Botschaft 0x28c CAN M POS 1 CAN M POS 2 CAN M POS 3 CAN M POS 4 19 e CAN Botschaften zum Speichern einer Speicherposition Fahrer TSG nur Botschaft 0x28c CAN M SAVE 1 CAN M SAVE 2 CAN M SAVE 3 CAN M SAVE 4 Ausg nge e CAN Botschaften zum Abrufen einer Speicherposition nur Fahrer TSG Botschaft 0x28d CAN M POS l1 CAN M POS 2 CAN M POS 3 CAN M POS 4 e CAN Botschaften zum Speichern einer Speicherposition nur Fahrer TSG
233. o not use this feature for modelling the TSG of the case study 10 3 4 Applied Target Platform Target code generation The tool support code generation for specific tar get micro controllers RoseRT generates C C or Java code RoseRT can be configured with any cross compiler so that almost any mirco controller is supported Supported targets These are the processor that toolset Rose RealTime user interface runs on sparc hppa x86 ppc Cygnus M68040 sh3 Code size lines of code and the used memory The host Simulation is Windows NT40T x86 VisualC 194 CHAPTER 10 RATIONAL ROSE REALTIME e 13627 lines of code in C with comments e 11319 lines of code in C without comments e 757 Kbytes of used memory Readability of code The code reflects the model very good In the latest VDC Venture Development Corporation report RoseRT is ranked number 1 we do not edit and use RoseRT generated code 10 3 5 Incremental Development We use an incremental Development for modeling the TSG of the case study going from a two axes system to the five axes version Reuse We had a very good reuse of the original specification Restricted changes Changes have been restricted to a small part of the specification At first we had 2 capsules for two axes system To become the five axes version we added simply 3 others capsules for the rest of the axes Modular design The tool helps building a modular design With the use of Ca
234. odel 22 CHAPTER 2 ASSESSING THE TOOLS Chapter 3 Result Summary Bernhard Schatz Jan Romberg Oscar Slotosch Martin Strecker While all the discussed tools are treated in detail in the second part in this chapter we give a short overall summary of the tools The aim of this section is not to give a detailed comparison between the tools rather we want to show the capabilities of tool based development as presented by the selected tools The discussed tools form a rather representative selection of the avail able tools for the development of embedded systems Therefore this sum mary also gives a snapshot of the state of the art of tool support for this domain 3 1 General Aspects Like in other domains of CASE tool support tools for the development of embedded software have made significant progress concerning general aspects including offered functionalities supported development phases documentation of the tool and their usability unsurprisingly all tools have some potential for improvement Most noticeable CASE tools have made strong improvements in usability but also aspects of functionality like the quality of the generated code offered consistency checks simulation and test automation 3 1 1 Functionality From a very abstract point of view the functionalities of the tools are quite similar The spectrum of supported functionalities includes e the design of the software using graphical description techniqu
235. odelling the case study Using Structure diagrams with capsules ports connectors and pro tocols you can describe in the same time the interaction the structure and the hierarchical structuring of the model These diagrams are a powerful combination to describe the model Rose RealTime uses the extensibility features of the UML to define some new constructs that are specialized for real time system development These new con structs allow code generation of elements that can use the services provided in the Services Library such as concurrent state machines concurrency message passing and timing services Unused notations The following diagrams have not been used too in our case study model 1 collaboration diagram It was not important to define during modeling the case study the roles that objects play in an inter action The interactions have been described in Sequence and Structure diagrams 2 deployment diagram It s not important in this case study to understand the physical distribution of the run time processes across a set of processing nodes We have to model the TSG only in the application layer 3 component diagram It s not important in this case study to show the dependencies among software components 10 2 3 Complexity of Description This section provide an estimation of the size of the built model Only the part of the specification used for executing the model simulation code generation have been consid
236. of a dif ferent prioritization of the axes led to a reorganization of the state charts The base of the whole model which means the highest layer in our hi erarchy including the three main units user management seat steering door latch without any statecharts and the belonging environment with the input ouput signals could be reused Restricted changes As aforementioned the changes are restricted to only some parts of the model The parts of the system not dealing with controlling the seat motors were not affected Modular design RiMC allows you modular designing So for example in the case study the door latch is a completely alone standing module And the control of the seat is split into different modules too It s also possible to build modules as so called generics that could be saved into libraries and reused in other projects Restructuring In RiMC you have the possibility to change the structure through the activity charts But then it s necessary to revise the mod ules which are involved in these changes 9 4 Conclusion RiMC in MicroC is a very impressive tool because it supports nearly all kinds of ways to implement the designed user model including parallel operations and hierarchy The user is able to separate his model in internal components and the environment what seems very helpful for modelling embedded systems RiMC disposes a clear structure of the model by its workarea browser illustrated by a tree an
237. of mes sages In Out signals exchanged between two capsules 10 5 MODEL OF THE CONTROLLER 197 ca lt lt Protocol gt gt BA BSProtocol lt lt Protocol gt gt lt lt Capsuk gt gt S24BProtocal BenutzerManagement from TSGDesign 20BPOS_HOR int BSPort aBPOS V int zint 20BPOS_H int 2 int lt lt Port gt gt aBPOS S int 3 int aBPOS W int W i 4 int 20GIBWERT_HOR void EUROS IM vert 1 int aSETZEWERT int 2 int aGIBWERT H void 3 int aGIBWERT S void 4 int aGIBWERT W void tl int a aGIBWERT V void S XR lt lt Protocol gt gt C3 Int CABProtocol u POS HOR int v r a POS_H int UE 38B MGMT int sspoS S int S1ABPort Bs int 7eM_POS_1 int a gt Pos_v int Bin Saute aoa 9M POS 2 int asPOS_W int lt lt Protpcol gt gt _wert_4 int aM POS 3 int S1ABProtocol lt lt Port gt gt _wert_3 int gt aM_POS_4 int S 20M_SAVE_1 int HT CH EN nM SAVE 2 int aMGMT 2 int _wert_3 int aMGMT 3 int int nMGMT 4 int i aMGMT SET int amp bmgmo leer int 1 ar 2 M_POS_1 int amp mgm3_leer int 1 a M POS 2 int M POS 3 int n M POS 4 int o M SAVE 1 int oM SAVE 2 int M SAVE 3 int uM SAVE 4 int Gpomgm4 leer int 1 I S1ABPort S1ABProtoco CABPort CABProtocol S24BPort S2ABProtoco BSPort
238. ollected For methods spezifical durations can be added The Document Generator then calcu lates the total duration for modeled sequences All real time relevant informations are only hints for hard and software developers and can not be validated automatically Although there is no sphisticated real time support for our purpose with the high level view the features were sufficient 5 3 Development Process This section discusses the development process we have used during the case study as well as the support ARTISAN RT Studio gave us managing it 5 3 1 Applied Process We started out with a system architecture diagram which is part of the Re altime Studio s enhanced features This is a black box perspective of the software system surrounded by the various interface devices and subsys tems as specified in the case study 5 3 DEVELOPMENT PROCESS 61 The next step was to identify and describe the use cases and to create the use case diagram To deepen the insights of the use case model we searched for possible realationships between the use cases and drew the according associations In the following each use case description was sophisticated by an ob ject sequence diagram which constitute the communication interaction between interface devices and the software system There we could reuse the objects from the system architecture diagram Afterwards we focused on the class modeling activity For every inter face device a corr
239. om ponents We also were able to create test data we could use again to show the simulation or to verify variations we transferred into the model AUTOFOCUS has a client server architecture which assisted us very much because we all three could work on our model without having to make copies of it and send them among each other But the question of authen tication appeared here as you do not have to authenticate accessing the repository server Furthermore AUTOFOCUS generates well structured C and Ada code Our model had a small C code size of 31 KB Test driver generation is also pos sible Surprisingly AUTOFOCUS ran pretty fast for a Java program Delays mostly occurred because of synchronization with the repository server 7 5 CONCLUSION 121 Last but no least AUTOFOCUS is a program which can be downloaded for free Also the C generator plug in is available in a unrestricted 30 day trial version 7 5 2 Weaknesses One of the major weaknesses of AUTOFOCUS is the instability It crashes often when synchronizing with the repository server If you have locked a component by accessing it and a crash occurs the lock sometimes is not suspended The graphical editors also don t run very stable The usability of the GUI is not so good too For example the size of text fields sometimes is not big enough scrolling does not function like it should and if you drag a component in the SSD editor ports you want to stay where they are move wit
240. on Readability of code Readability was found to be good for all ofthe evalu ated tools All of the tools use identifiers from the model in the code if state machines are implemented the structure is generally repli cated in the code s control structure Comments from the models are usually included in the source files 3 3 5 Incremental Development Reuse restricted changes and modular design Support for reusability and the restriction of changes to localized parts of the model were gener ally found to be adequate All of the evaluated tools supported some notion of a reusable component or actor thus simplifying architec tural changes and reuse of existing components As the only research tool in the comparison AutoFOCUS was found to lack support for bottom up structuring Moving from the first iteration to the second changes in the specification were found to be restricted to some com ponents not affecting the specification as a whole Reuse of partial 40 CHAPTER 3 RESULT SUMMARY specifications was typically performed by simple copy paste mech anisms library mechanisms as in Matlab Simulink and AutoFocus have also proven to be helpful Restructuring As of now most of the tested tools lack automated support for restructuring and refactoring As a notable exception the two UML RT tools Rose RT and Trice offer automated composition and decomposition of actors aggregate function 3 4 Conclusion Table 3 1 gives
241. on are updated by the actual values After that the class returns to the begin state Chapter 12 Trice Tool by Protos Software GmbH Clemens Lanthaler Petr Ossipov Tania Fichtner 12 1 General Aspects The protos product range includes software development tools software components and consulting and training services with the emphasis on the areas of embedded systems and machine control software Functionalities Trice supports modeling simulation testing automated documentation validation and verification as well as execution on both development and target platforms Development phases Trice is not only present during the development phases it is present for the whole project running time Because of the automatic code generation and integration of the application and graphical model the separation between the stages for analy sis design implementation testing and maintenance service is re moved The graphical model can be directly run with the in between step of code generation At the start of a project Trice can be used to carry out the analysis of the system and to list requirements During the modeling and graph ical programming of operations it is possible to generate the running application test it and monitor it The findings from each respec tive test flow directly into the development process This eliminates concept breaks between project activities and efficiently supports the development process As
242. onality The reuse of classes spared a lot of time and made the resulting structure of the system more readable and easier to understand During all phases of implementation we used Offline Experiments to test our components and to simulate their functionality Finally we integrated all modules into one big project and did the Offline Experiments again To validate the functionality of this project efficiently we made a little experi ment environment 6 3 2 Applied Process Support Simple development operations ASCET SD provides many useful oper ations that we could use cut and paste not only one component but whole parts of a diagram replace components by drop them the new on the old one and drag components into a diagram 6 3 DEVELOPMENT PROCESS 85 Complex development operations The tool offers also complex develop ment operations such as the automatic sequencing of processes and the auto code generation The generator supports various target plat forms PC PPC Motorola MPC5xx controller etc and optimises the code for them to reach maximum performance and precision The arithmetic and especially the integer code generation pose a special challenge here A simple arithmetic expression like c a b has to be transformed to C A 4 B 5 because of different quantisations of the variables 0 01 for a 0 04 for b and 0 05 for c For the values a 1 b 0 6 and consequently c 1 6 the result with the above quantisat
243. oned above including their corresponding questions are listed 2 General Aspects In this section general information about the tool is provided 15 16 CHAPTER 2 ASSESSING THE TOOLS Functionalities Which functionalities are supported by the tool e g mod eling simulation documentation configuration management test man agement test case generation model validation and verification Development phases During which development phases the tool can be used requirements analysis design implementation test deploy ment Documentation How good is the documentation of the tool functionali ties differ between manual and online help system very good good satisfactory enough inadequate Usability How good is the usability user interface of the tool very good good satisfactory enough inadequate 2 2 Modeling the System This section provides information on how a system is modeled using the description techniques supplied by the tool Special emphasis is laid on what kind of concepts and notions are applied to model a system how complex the resulting descriptions are and what kind of operational model is used to interpret the description In each subsection examples from the modeled CASE study are used to illustrate the answers whereever suit able possible 2 2 1 Available Description Techniques This subsection lists the notations and concepts provided by the tool Supported notations Which notati
244. ons constructs diagram types are offered by the tool e g class diagrams state machines sequence di agrams Modeling aspects Which aspects can be modeled using the notations ac cording to the tool vendor e g behavior structure interfaces inter action Type of notation What is the representation type of the notations e g tabular text graphic Hierarchy Does the notation support hierarchical structuring e g com ponent subcomponents state substates 2 2 MODELING THE SYSTEM 17 2 2 2 Applied Description Techniques Approaches with a large variety of description techniques often offer differ ent notations to describe similar or overlapping aspects e g Collaboration Diagrams and Sequence Diagrams in UML Since in those approaches not always all notations are applied this section focusses on the description techngiues applied in the case study Applied notations Which notations constructs diagram types have been used during modeling the case study Modeled aspects Which aspects have been modeled real application e g behavior structure interfaces interaction Notations suitable Are the notations suitable for modeling the case study Clearness Do the notations allow to build clear and readable models Unused notations Which notations constructs diagram types have not been used for modeling the case study reason Missing notations Which notations were missing while working o
245. ontroller The Logical view of the model consist of four modules e TSG Design e Komponenten Design e Object Model These are described in detail in the following sections 196 CHAPTER 10 RATIONAL ROSE REALTIME 10 5 1 TSG Design the following Diagram describe the structure of the TSG nd SLASPorty sitzEinstellungR1 S2A4 Port na OutSLAsPort OutSPASPort SiPort tsgAdapterR1 r m OutgasPort m CarPort InCanPort M OutS1ATPort D CASPort 4 SBPort S1ATPori tuerschlossR1 Dr outcaTPort OutCABPort CATPort I i OutS1ABPort oo SibBPort OutS2ABPort C BPort benutzerManagementR 1 S2 BPort the main elements in the TSG capsule are 1 SitzEinstellung this capsule handles all signals associated to a mod ification of the seat position 2 BenutzerManagement this capsule stores general seat position 3 T rSchlo this capsule sends signals to close and open the door lock 4 Adapter this capsule manages all TSG incoming outgoing signals from S1 Stecker S2 Stecker Can bus Every Signal will be relayed to the appropriate capsule 10 5 2 Komponenten Design BenutzerManagement Design e Structure The following class diagram show the protocols of Be nutzerManagement capsule Each protocol represents the set
246. or channel based systems relying on 1 1 communication a multi cast mechanism can reduce unnecessary con nectivity Concerning support for the real time aspects of embedded systems there are different possible approaches Timed model The operational model explicitly deals with time Depend ing on the synchronization mechanism of the model there are differ ent variants event driven models generally use some form of timeout event triggering behavior time driven models usually have a sched uled execution model supporting access to some system clock vari able 3 3 DEVELOPMENT PROCESS 33 Timed deployment The operational model does not directly deal with time At most timing conditions can be added as annotations Different timing models are used in the tools ARTiSAN ARiTSAN delegates the real time aspects to the implementa tion and deployment phase ASCET SD ASCET SD uses a time driven model with individual fre quencies based on the operating system with a variable indicating the time difference to the last execution time AutoFocus AutoFOCUS uses a time driven model with a universal clock timers can be introduced based on the global clock tick MATLAB StateFlow MATLAB StateFlow uses a time driven model with individual frequencies based on the operating system with a vari able indicating the system time as well as special time event Rose RealTime Roses uses timeout events generated from a timing ser vice
247. or modeling the system Clearness The diagrams consist of self explaining graphical elements so the meaning can be understood quickly According to the UML specification only a few different elements can be inserted into every diagram type The graphical representation of the model is clear and straightforward because details are kept separated in a property window Unused notations We have not used some of the offered notations These were e Activity Diagram e Concurrency Diagram e Object Collaboration Diagram e Table Relationships Diagram e General Graphics Diagram 5 2 MODELING THE SYSTEM 59 e Text Diagram We were able to model the whole system with the applied notations Ad ditional diagrams would have contained redundant informations or were not necessary for our purpose Missing notations We have not missed any notations 5 2 3 Complexity of description In this part we only consider diagrams which are used for executing simulating the model These are the state and class diagrams Views Five state diagrams and one class diagram were used Nodes State diagrams In all there are 24 nodes The maximum per view is eight average is five Class diagram 13 nodes Edges State Diagrams 50 Edges were used The maximum is 18 average is ten Class diagram 16 edges Visible annotation State diagrams 152 annotations are visible maximum is 56 average is 30
248. ore the level of abstraction does of course influence the complex ity e g using abstract signals instead of CAN bus signals Nevertheless the complexity of the specifications is more or less within the same order of magnitude for the tools Especially the average complex ity per view is similar between most tools 4 nodes 7 edges this indicates suitable modular description techniques supporting readable designs In short the following complexity measures were obtained 30 CHAPTER 3 RESULT SUMMARY Views The number of views varies between 14 and 90 with an average around 40 views used to model the controller Nodes A total number of about 100 nodes average where needed to model the system the average number of nodes per view is about 4 Edges The total number of edges used in the specification ranges about between 150 and 300 edges the average number of edges per view is about 7 Visible annotations The average length of visible annotations used to specify the controller is between 30 and 60 Invisible annotations While in most tools no invisible annotations where used in some tools e g AutoFOCUS complex annotations like tran sition triggers where hidden and replaced by a short explanatory la bel For some of the tools the reported figures are outside this range With ARTISAN the statistics were applied to the more abstract design leading to a deviation from the mean Due to its operational model tuned espe
249. ort S2ABProtoco W log Log CutS2ABPort S2ABProtncole BSPort BSProtocal e state diagrams Example Schalung einstellen State Chart Diagram 182 CHAPTER 10 RATIONAL ROSE REALTIME Schalng enger s enger Schalung weiter weiter e capsule structure diagrams Example Structure Diagram for the capsule StizEinstellung SBPort a Controller ie sitz_vor_zurueckR1 Controller2 se steiler flacherRi SBPort x Contfoller1 controllerR1 schalung_enger_weiterR1 z Controler 3 S1ASPart S1ASPort Controller4 4 CASPort oO flaeche_hinten_sinken_hebenR1 Controller4 0 flaeche vorne sinken hebenR1 Controlbr5 e sequence diagrams Example Sequence Diagram for the use case T rEntriegeln 10 2 MODELING THE SYSTEM 183 canBusR2 LinkeTsg SteckerS1 i CanBus Zyklische Nachricht zur can Zustand beibehalten 1 ZV SCH 00 te 1 KEY_STATE L 1 1 ZENTR_MOT1 12 1 2 ZENTR MOT2C1 1 3 ZV SCHL L 10 1 4 BLINK 1111 1 5 DURATION 100 e deployment diagrams e component diagram e collaboration diagrams dynamic structure Modeling aspects Diagram modelling aspects e use case diagrams depict actors and use cases together with their relationships The individual use cases represent function ality or requirements of functionality
250. osition 10 Anschl sse 9 SPOS HOR 10 SPOS V 11 SPOS_H 12 SPOS_S 13 SPOS_W Charakteristik Widerstandswert 1 KQ bis 10 kQ Wertebereich wird i d R nicht ganz ausgenutzt bei Endanschlag Unterbrechung Kleinere Werte geben an da Sitz Lehne Schalung weiter vorne h her steiler bzw enger sind Sitzmotor Anschl sse 32 SMOT_HOR1 33 SMOT_HOR2 34 SMOT V1 35 SMOT V2 36 SMOT_H1 37 SMOT H2 38 SMOT_S1 39 SMOT_S2 40 SMOT_W1 41 SMOT W2 Charakteristik siehe Tabelle 3 Die Leistungsaufnahme je Motor betr gt max 15 W Sitzeigenschaft K rzel Bewegung bei 12 Bewegung bei 12 V Geschw V Entfernung Sitz Lenkrad HOR nach vorne nach hinten 0 9 cm sec Sitzfl che vorne V heben Senken 0 7 cm sec Sitzfl che hinten H heben Senken 0 7 cm sec Schalung S heben Senken 0 5 cm sec Lehnenwinkel W steiler Flacher 3 3 sec Tabelle 3 Sitzmotoransteuerung Schliefimotor Zentralverriegelung Anschl sse 43 FZENTR_MOTI 44 FZENTR MOT2 Charakteristik 12 V f r 2 sec 0 3 sec verriegeln die T r 12 V f r 2 sec 0 3 sec entriegeln die T r Die Leistungsaufnahme des Schlie motors betr gt 18 W 3 2 3 Stecker S3 Energie und Kommunikation Die Kontaktierung ist durchg ngig mit versilberten 0 63mm Kontakten im Macro Tripplelock System auszuf hren Abbildung 9 zeigt das Steckerbild Tabelle 4 beschreibt die Belegung des Steckers im berbl
251. ot block while the mes sage is in transit Communication model suitable We used only buffered asynchronous com munication This mode is well suited for modeling the TSG of the case study Timing constraints To access the timing services you reference by name a timing port that has been defined on that capsule that is by cre ating a port with the pre defined Timing protocol Service requests are made by operation calls to this port while replies from the service are sent as messages that arrive through the same port If a time out occurs the capsule instance that requested the timeout receives a message with the pre defined message signal timeout A transition with a trigger event for the timeout signal must be defined in the be havior in order to receive the timeout message Each request to the timer service for a timing event will return a handle to the request This handle can be used to cancel the request Sufficient realtime support The realtime support is sufficient for model ing the case study e Rational Rose uses the extensibility features of UML to define some new constructs that are specialized for real time system 190 CHAPTER 10 RATIONAL ROSE REALTIME development For example Capsules are simply a pattern for providing light weight concurrency directly in the modeling no tation A capsule is implemented in Rational Rose RealTime as a special form of class Capsules allow the design of systems that can handle man
252. ot offer any ad ditional features Host Simulation Support The tool supports a very effective mechanism to do the simulation on the PC or on the workstation This mecha nism is the so called Offline Experiment The compiled model is executed directly on the PC The tool offers two possibilities to find modelling errors very fast Via the run time display of parameters during Offline Experiments and doing the execution of the program step by step the processing of the program can be observed very well Figure 6 9 Experimental system ES1000 2 6 3 DEVELOPMENT PROCESS 87 Target Simulation Support ASCET SD also supports the test of the model on the target hardware The code for the target platform can be gen erated directly on the PC using the Target Integration Package and can then be incrementally integrated on the target hardware This integration process is accompanied by the so called Online Experi ment which helps to validate the functionality of the generated code for the target hardware in real time With the ES1000 2 see Fig 6 9 on page 86 ETAS offers a modular experimental system that can be eas ily configured as the prototype of a particular target hardware The ES1000 2 can be associated with other measuring instruments such as a potentiometer with the PC for displaying input and output pa rameters It can also be associated with the target micro controller to allow incremental integration of new functionality
253. owever can related code level 36 CHAPTER 3 RESULT SUMMARY errors back to the model e g by relating a compiler error to the rele vant element of the model Syntactic Diagram Level On this level the tool makes sure that a sin gle diagram or view is well formed This is the most basic form of model consistency Examples are e Well formedness of trigger expression e Well typedness of communication paths channels and ports have the same type Syntactic Model Level On this level the tool ensures syntactic consis tency between diagrams referencing the same elements of the model Examples are e Definedness of types e g types used for messages or variables are defined e Definedness of messages e g messages used in an interaction description Sequence Diagram are defined according to the type of the channel as defined in the structural description Architecture Diagram Semantic Diagram Level On this level the tool ensures well definedness of a single diagram usually requiring some form of execution or ver ification Examples are e Non determinism of behavioral descriptions e g no two tran sitions from one state can be enabled by the same triggering evens e Completeness of behavioral description e g for each possible triggering event there is an associated transition Semantic Model level On this level the tool ensures that the dynamic aspects of the description are consistent generally this re
254. part support the development of reactive software systems they differ concerning how specifically they address the development of embedded software As a re sult they focus on different aspects of the development process e g mod eling the system under development supporting the test of the system or generating and deploying code to the embedded controller Therefore to simplify a comparison of the different functionalities offered by the tools the tools were analyzed according to different criteria which we present in a structured format in the following sections After giving a short overview of each tool the modeling concepts of the tool as applied in the case study are discussed focusing on its descrip tion techniques the complexitiy of the resulting description of the system and the interpretation i e the operational model behind those descrip tion techniques In the next section the process support offered by the tool is discussed specifically addressing issues concerning functionalities sup porting the modeling of the system qualitiy assurance deployment and incremental development After a short conclusion giving a short sum mary of the tool as well as some of its pros and cons the model of the controller as developed using the tool is illustrated in detail For each of the sections a list of questions is defined to illustrate the functionalities of the analysed tools In the following the sections men ti
255. pecific aspects e g bus schedules task switching are not modeled explicitly Therefore to obtain deployable code those aspects are laid off to the coding phase outside the modeling capability of the tool leading to similar prob lems as with implementation level models Using a Draw and Generate Tool Domain specific approaches generally support a more detailed model including aspects like preemption or time driven communication allocatable to bus slots these tools make use of this information to generate deployable code However gener ally sophisticated analysis techniques are not available on the level of the model therefore the analysis of defects introduced on the level of the model is performed manually or is delayed until the execution of 45 the generated model Thus e g the consistency between time driven communication and allocated bus schedules is not ensured Using a loosely coupled tool chain A loosely coupled tool chain gener ally splits the development process in tool related phases with sub stantial gaps between those phases often a high degree of integra tion is missing Examples for those gaps in the development pro cess are scenario based descriptions of the behavior that cannot be used to generate equivalent test cases on the implementation level or counter examples generated by verification or validation on the level of implementation which are not expressed on the level of the abstract system Therefor
256. pen bie take 96 ibp ee tire 2 pew rig ne aer m kw AN BATT bat 2 zT ket opes rig Figure 12 7 Sub state machine TOP WillVerriegeln CheckVorraussetzungen 12 5 MODEL OF THE CONTROLLER 245 Benuztermanagement BMGT is an actor responsible for user profile saving and loading It communicates with both radio keys and with SS It does not contain any sub components actors Sitzsteuerung Actor SS manages the movement of all 5 chair axis for the manual and the automatic BMGT modes It communicates with BMGT speed sensor battery and left door It contains multiple actor instances inside Axis Five instances of seat axis model the different seat positions that can be set by the user These instances contain the chair position change switch motor and simulation of seat position changes textitCounter This actor controls the position changes of all seat axis assuring that position changes happen in the proper order Environment Environment consists of doors their motors speed sensor battery starter two radio keys and right TSG The functionalities of the modules are the following Benutzermanagement is the user management module which func tionality is saving and restoring chair positions When restore process is initialised by the user appropriate position is loaded and then sent to the SS Saving process gets the actual position from the SS and saves it internally Sitzsteuerung is a module
257. pent e Ente re e pepe oe SER de ias 5 2 0 l rschlo e deer t pa Ot et ERE RE d t bel Eres chem en Pe NEE 6 Komponentenbeschreibung eessesseseseseeeeeeeene enne nnne erre en nr en nennen nennen nnne 7 3 1 Position am Eahrzeug o ect b A IR EIER 7 32 Schnittstellen utere Ren e e e t th a dec dee effekt 8 3 2 1 Stecker SI Turelemente ouenne cus e n REY ERU TO UD ER TUER 8 3 2 2 Stecker S2 Externe Elementen eannan niee e ins oaa Eea nE aaar i 9 3 2 3 Stecker S3 Energie und Kommunikation sss nnn 11 3 3 Blektnsche Spezifikation es ee idee SF RET Era ce Le Phe E ae ee e e Rea 12 3d Geh use Hu uses EUER Eder 12 en WB Coilci iE 13 jab SW 17 5 1 Allgemeines Verhalten 45 eon Ree Rn En p D ed 17 3 2 wSitzeinstelluhg 2 222 ER AR e ehe eta ease von dee Ea eie EE Pre IRR RETE ARR TERES 18 5 35 Benutzermanagemlerit eerte Lied cedet eet ie EISE eee ree pop a TERT t n 19 DA D rschloDBzian ettet vet d ie nn ur Hn bet Pede rts IN re po n 20 Zus tzliche Richtlinien zur Modellierung eese enne enne 23 6 1 Inkrementelle Entwicklung ener nne nnne enne 23 62 Umgebung cue ier ee pet e n a cet to m tud 23 6 3 Abstraktionen f r Hardware und Bus Kommunikation see 23 6 3 4 Hardware Schnittstelle esee enne tenentes 23 6 3 2 GCAN Schnitistelle 2 treten eet ote ue ie eo ER PE I ERI eset 23 1 Einleit
258. pport simulation on the target hardware Are all the features of host simulation available Adequacy How adequate are the simulation mechanisms e g numeric simulation by curves graphics instead of tables Debugging Features Which features are available Examples are Break points Event injection Run time display of variables Debugging at model level or code level Testing How does the tool support testing Can test vectors be played into the model Can test vectors be generated from models Are there further analysis capabilities Are there interfaces to other test tools e g Rational Test RealTime Certification Are code generators certified by an independent certification authority For simulation code For target code Are there any certi fied code generators available Requirements tracing Does the tool support tracing of requirements in the development process Are there interfaces to requirements engineer ing tools e g RequisitePro DOORS MS Word 2 3 4 Applied Target Platform Since code was not deployed in his case study this section gives only a short overview about the code generated out of the model of the system Target code generation Does the tool support code generation for specific target micro controllers Supported targets Which target plattforms micro controllers operating systems are supported by the tool Code size What is code size of the generated code for the target platform lines of
259. psules a RoseRT model is component based by design Restructuring The tool support restructuring techniques e g aggregate you can select capsules from the structure diagram and by clicking of the aggregate function they will be aggregated to one super capsule decompose the opposite of the aggregate function reorganizing in heritance structure cardinality 10 4 Conclusion Here is short summary of the strengths of the tool 10 5 MODEL OF THE CONTROLLER 195 Modelling notations suitable Use Case class Modelling Collaboration role modelling Interaction Modelling sequence diagrams Component Modelling Deployment Modelling Visual Execution Host Execution C Language Support Java Language Support Data Class Code Generation Tools Interworking Rational ClearCase SourceSafe PVSC UNIX only Microsoft Visual SCCS RCS Rational SoDA requires Rational Rose RTime domain Rational RequisitePro Rational Purify Model Documentation Report Generation Web Publisher Online Documentation The content is fully searchable and contains rich multimedia Here is short summary of the Weakness of the tool Saving Diagrams it s difficult to save a diagram as a Graphic format gif jpg Copy and paste feature it s not possible to transfer a diagram form a model to another with copy and paste 10 5 Model of the C
260. quires some form of symbolic execution or verification Examples are e Consistency between a behavioral description and an interac tion description e g between State Diagram and Sequence Di agram e Consistency between interaction descriptions e g between sev eral Sequence Diagrams Syntactic diagram level consistency can either ensured constructively or by analysis Examples of the first form include editors accepting only struc turally well formed diagrams all tools editors accepting only well formed trigger conditions e g Rhapsody or structural editors supporting only 3 3 DEVELOPMENT PROCESS 37 the construction of a connecting channel between ports of corresponding types e g Simulink StateFlow Examples of the second from include ed itors checking well formedness of trigger conditions e g AutoFOCUS or checking the well typedness of channels e g Tau Syntactic model level consistency too can either be ensured construc tively or by analysis The first form is often realized using a common syn tactic model for all views e g in form of a repository the constructive approach includes using only defined messages for channel in a Sequence Diagram e g Rose RT The corresponding analytical approach uses an additional check to ensure this property e g Tau Semantic diagram consistency is generally not supported by tools Few exceptions exist e g the non determinism check AutoFOCUS Finall
261. r 2 in soll wert EP AOV in soll pos s in out hor motor 1 Sue in wergleicher pos s furks ender E start sizeinstellung out hor motor 2 a 4 out motor 1 sitz pos hor motor 1 out ww motor 1 32 s pos wiin iet wert sitz pos hor motor 2 COR out motor 2 out w motor 2 soll wert sitz pos w motor 1 reset sitz_pos_w_motor 2 out s motor 4 soll pos w in n L pos v in wergleicher pos w j sitz pos s motor 1 out s motor 2 Figure 6 11 Part of the block diagram for the seat adjustment shows the reuse of classes Restricted changes Changes because of the extension had to be made in different modules No class had to be adapted Only the control logic had to be extended and refined Modular design The possibility of building reusable code offered by ASCET SD helped a lot in building a modular design for each module AI though the inner life of the modules looks a little bit confusing you can understand the organisation of the modules and the cooperation of the different instances of the classes Restructuring The tool does not really support restructuring techniques such as refactoring 90 CHAPTER 6 ASCET SD 6 4 Conclusion In this section we give a summary of the strengths and weaknesses of ASCET SD and its application As well we specify what we missed dur ing the modelling and also ASCET SD s helpful features During the mod elling of our case study we got to know the tool with many of it
262. rably influences the UML2 0 specification So at least at the beginning a lot of notations remained unclear to us Also the documentation of the tool itself does not sufficiently explain the graphical descriptions Tau provides For most problems the on line help gives easy and quick information also using examples 11 5 MODEL OF THE CONTROLLER 221 Certainly one of Tau s biggest benefits is that it is very very comfort able to use The graphical user interface allows to define large parts of the models by merely click and drop avoiding entering code manually as far as possible Already defined elements can be dragged and dropped into new diagrams or moved consistently to other nodes of the model view If you rename a node in the tree view all diagrams are updated Positive to mention is that Tau in contrast to most other tools on the market can be applied for the whole software development process It gen erates runnable software applications only out of the modeled diagrams and without writing one line of code To conclude Tau is one of the most powerful and advanced modeling tools on the market With UML2 0 they decided to use a promising nota tion that will most likely become the standard modeling language in the next years 11 5 Model of the Controller In this last section we will give a short introduction to the model of the the controller we built for the case study First the basic components we defined will be explained Th
263. raphically represent all 48 signals as nodes but 11 2 MODELING THE SYSTEM 211 we chose the 10 interfaces and the 7 internal signals So altogether we have 36 nodes and 5 1 nodes view The 5 architecture diagrams contain 8 different parts and 11 different ports as every class has exactly one instance Some parts are used in more than one diagram so altogether there are 17 parts visible A port is only made visible in an architecture diagram if it is needed lead ing to 20 representations of ports Summing up there are 37 nodes leading to 7 4 nodes per view The last code relevant diagram type the state chart diagrams defines the behavior of the 8 classes Altogether there are 27 different states one class having 11 states one 9 one 2 and the rest each having 1 state which makes an average of 3 4 states class Due to their complexity the state machines of single classes were split up to 44 state charts diagrams In order to improve readability even more we avoided drawings graphs with cycles instead we repeated a state several times within one graph This is also the recommended model ing technique of Telelogic The diagrams contain 258 graphical repre sentation of states 142 signal symbols 125 task symbols 123 decision symbols and 263 guard symbols Per view the numbers are 5 8 3 2 2 8 2 8 6 0 altogether we counted 911 nodes and 20 7 nodes per view in state chart diagrams Edges Now we want to make some statistics a
264. raphs the main modules of our model are de scribed Component BENUTZERMANAGEMENT The activity chart BENUTZER MANAGEMENT administrates the user management and controls the au tomatic adjustment of the seat position based on user profiles 9 5 MODEL OF THE CONTROLLER 173 POSITION Figure 9 10 Activity chart BENUTZERMANAGEMENT Therefore it has the ability to communicate both with the chart SITZS TEUERUNG and the chart TUERSTEUERUNG through input and output data flows It is furthermore connected to the activity chart SPEICHER which handles persistent storage of the seat positions for the different user profiles The environment activity BENUTZERMGMTTASTER is the source of all input signals coming from the user devices i e buttons on the user panel signals from the two wireless keys etc A screenshot of the activity is shown in Figure 9 10 The activity BENUTZERMANAGEMENT itself consists of a single con trol activity which encapsulates the state chart BENUTZERMANAGEMENT_C Fig 9 11 When this state automata started it first remains in the state IDLE and waits for user input When the user gives the command to store the actual seat position to a certain user profile the chart changes into the state SPEICHERN and passes the values of the five axes onto the CAN bus After this is done it returns to the idle state Another possible user command is the request of a certain seat position stored in a user profile In th
265. rate window see lower right window The different ways of running the simulation where very usefull be cause we could start the simulation with different signals and let it run and we only had to do the simulation step by step if there where an error For example one time the door wasn t unlocked after the simulation although it had to be By doing the same simultion step by step we ramarked that the battery was to low because it was initial ized empty and the signal with the new value has not been received So we found that the signal had been sent but a different part had re ceived it After renaming the signal that the other part should receive the simulation ran through correctly To sum up all debugging is done at model level Testing The model verifier is not only suitable for debugging but also for testing Either you can enter signals sent to the model manually or you can store a sequence of signals and let it run as a test case Certification The code is not certificated but it complies with Telelogic s own XML specification Requirements tracing Requirements tracing is not supported by Tau itself As the requirements engineering tool DOORS is also produced by Telelogic it is fully integrateable into Tau 11 3 4 Applied Target Platform Target code generation Telelogic Tau generates C or C source code This code is always compilable as long as the model verifier can be started Supported targets C as well as C
266. rent micro controllers the code should become more readable 6 3 5 Incremental Development Reusing the classes that we built for the two axes system it was no prob lem to expand the system to the five axes version Also the connection structure between components remained more or less the same as before The incremental development process is supported very well Reuse The original specification remained more or less the same because the functionality of an axe is encapsulated in some classes New axes could be added by adding further instances of these classes The con trol logic of the five axes system had to be expanded and became more complicated hi iio fm f out mea s2 spos hovin Et wert out motor 2 out hor motor 1 furksender start_sitzeinstellung out_hor_motor_2 soll wert sitz pos hor motor 1 out v motor 4 I sitz pos hor motor 2 soll pos hor in out w motor 2 sitz pos w motor 1 sitz pos w motor 2 out s motor 1 gt S out motor 1 sitz pos s motor 1 out s motor 2 52 spas win it wert sitz pos s motor 2 LS out motor 2 out v motor 4 soll wert sitz pos v motor 1 reset sitz pos v motor 2 out v motor 2 soll pos win in vergleicher_pos_w Erin sitz pos h motor 1 out h motor 1 sitz pos h motor 2 out h motor 2 mo out_motor_1 er ee Re out_motor_2 i en t moto
267. rly analysis and design phases making analysis and gen BIBLIOGRAPHY 47 eration support available even at early stages of the development pro cess e g completion of state based description of a component to introduce standard behavior for undefined situations Integration by Analysis The relation between different models during the development is supported This includes the analysis of different models used during the same phase e g checking the consistency of a exemplary sequence diagram and a complete state transition de scription of a component as well as different phases e g checking a bus communication schedule against the abstract communication behavior of the corresponding abstract component This leads to a higher level of product quality especially by supporting analysis of the system at earlier stages furthermore it also increases process effi ciency by supporting earlier detection of defects Integration by Generation The transition between different views or ver sion of a model in the development process is supported by generat ing views or versions of the model out of each other This includes forward generation i e from a view of an earlier phase to the view of a latter phase e g the generation of test cases from a behavioral description as well as backward generation i e from an implemen tation view to a more abstract one e g the generation of an abstract scenario based description from an execut
268. rly phases than those later phase techniques e BMJH96 shows that especially in a development process requiring a high level of product quality CASE support can significantly increase productivity Productivity is measured in implemented function points per time unit 46 CHAPTER 4 MODEL BASED DEVELOPMENT In our understanding see also SPHPO2 a model based software devel opment process requires e a product model integrating different views of the system for differ ent stages of development and different levels of abstractions e a CASE supported development process offering techniques to ana lyze the product model on all levels of abstraction and supporting transitions between those levels These properties have immediate consequences on how a tool should sup port a model based development process it concerns what aspects or views of the system under development should be covered by the tool as well as what kind of operations should be offered by the tool to analyze or trans form the model Adequate Models During the development process different aspects of the system under development must be addressed for the domain of embedded systems e g overall functionality time and resource limitation partitioning and deployment scheduling during different phases e g requirements analysis design implementation integra tion Specific views must be available for these phases Since soft ware systems and especia
269. rm sess 169 9 3 5 Incremental Development 2 5 22 2 170 94 Conclusion 22 22 2 Cm onen 170 95 ModeloftheController lees 172 Rational Rose RealTime 179 101 General ASpECIS anssi Tu Rog dnm ea cp rea 179 10 2 Modeling the System 2 ue Hs cire fue we s 180 10 2 1 Available Description Techniques 180 10 2 2 Applied Description Techniques 187 10 23 Complexity of Description 188 10 24 Modeling Interaction 2 2 22 189 10 3 Development Process rar Fr ara A SS 190 10 9 D Applied Processi i uc eR era wg 190 10 3 2 Applied Process Support 190 10 3 3 Applied Quality Management 192 10 3 4 Applied Target Platform lise 193 10 3 5 Incremental Development 194 10 4 Conclusion o ooo a 194 10 5 Model of the Controller aoaaa 195 10 94 TSG Desigh EUR E 196 CONTENTS 10 52 Komponenten Design s mE 1053 Object Model x5 sere ce te X t eae a 11 Telelogic Tau 11 1 General Aspects 4 vay Wes xem e a 11 2 Modeling the system 4 22 2 2 0 ae Eres 11 2 1 Available Description Techniques 11 2 2 Applied Description Techniques 11 2 3 Complexity of Description 2 22 2200 11 2 4 Modeling Interaction llle 11 3 Development Process d dI S a 11 31 Applied Process 2 23 4 ae eo EI E 11 3 2 Applied Process Support 2 22 sus Ce ma ex 11 3 3 Applied Qu
270. rstellung ber die Sitztasten eine Taste des 18 Benutzermanagements gedr ckt siehe Abschnitt 5 3 so wird die Sitzverstellung ber Tasten abgebrochen und die Sitzverstellung ber das Benutzermanagement begonnen Ist die Batteriespannung BATT w hrend der Sitzverstellung kleiner als 10 V so werden die Sitze nicht bewegt bzw wird die Sitzbewegung abgebrochen Statt dessen wird die Meldung B LOW SITZ 1 generiert Bewegung ber Benutzermanagement Die Sitzverstellung ber das Benutzermanagement ist nur m glich solange die Fahrzeuggeschwindigkeit FZG_V kleiner als 5 km h ist Uberschreitet die Fahrzeuggeschwindigkeit 5 km h so wird die Sitzbewegung sofort abgebrochen Es sind zwei F lle zu unterscheiden e Fall 1 Auswahl einer Einstellung ber Benutzermanagementtaste o In diesem Fall ist anzunehmen da der Fahrer bereits auf dem Fahrersitz sitzt Um die Bewegung so angenehm wie m glich zu gestalten sind folgende Regeln bei der Ansteuerung der Sitzposition zu beachten Zuerst werden die Bewegungen durchgef hrt die eine Entspannung der Sitzposition zur Folge haben d h das Vergr ern der Entfernung Sitz Lenkrad das Flacher Stellen des Lehnenwinkels das Absenken der Sitzfl che vorne und hinten sowie das ffnen der Schalung Anschlie end werden die entgegengesetzten Bewegungen durchgef hrt Es d rfen zu einer Zeit maximal zwei Richtungen gleichzeitig bewegt werden Dabei gilt die Reihenfolge E
271. s 11 2 2 Applied Description Techniques Applied notations For our system we used class diagrams architecture diagrams and state chart diagrams Which type of diagram was used for which aspects is described in the following section Modeled aspects As we got a specification of our system we left out the use case and interaction analysis and started directly with modeling the basic elements of the system with class diagrams and the structure of the system with architecture diagrams The interfaces were created in a class diagram using the predefined interface stereotype The interfaces contain signal stereotypes and are grouped in an interface package So all the interfaces are separated from the rest of the code and someone who wants to use the software only needs to look at the interface without searching it in the rather complex and large rest of the system For the simulation of the system we created an environment that sim ulates the signals that are sent from the three connectors to the Tuers teuergeraet This environment simulates the interaction of the Tuer steuergeraet and the car For example if the Sitzeinstellung sends the signal to move the seat our environment receives this signal and sends the information that the seat has been moved in the demanded way to the Tuersteuergeraet For the interaction with the TSG you only have to send events to the simulation that are triggered by the user like Button XY presse
272. s actually the composite behavior of all its components However the collaboration does not identify global relationships between its capsule role sequence diagrams An interaction is a pattern of communica tion among objects at run time A sequence diagram is used to show this interaction from the perspective of showing the ex plicit ordering messages Sequence diagrams are often used to show specific communication scenarios of a collaboration Se quence diagrams are particularly important to designers because 10 2 MODELING THE SYSTEM 185 they clarify the roles of objects in a flow and thus provide basic input for determining class responsibilities and interfaces diagrams deployment diagrams provides a basis for under standing the physical distribution of the run time processes across a set of processing nodes There is only one deployment view of the system Nodes may contain component instances which in dicates that the component runs on the node e component diagram A component diagram show the depen dencies among software components A software module may be represented as a component Some components exist at com pile time some exist at link time some exist at run time and some exist at more than one time A compile only component is one that is only meaningful at compile time The run time com ponent in this case would be an executable program A com ponent diagram has only a type form not an instance form To s
273. s different from the real one the corresponding motors will be triggered After every seat axis has reached its desired value the seat adjustment stops its work This process occurs in a certain priority order realised by a special class On the other hand if the trigger of this whole process was the radio transmitter the priority order will not be considered and another class is used during the execution see Fig 6 19 on page 99 generated motor signals current seat position desired seat position Br si radio transmitter signals to motors Figure 6 19 Functionality of the seat adjustment Another way to calibrate the seat is to do it manually Therefore there are push buttons next to the seat The signals generated by these push buttons are also sent to the seat adjustment In this case the motors are triggered immediately without any comparison The only restriction in this case is that at most two of five motors may be active atthe same time Even this is realised by a class An important feature of the seat adjustment required by the specification is that in every case the last button pressed has to be considered This means that the seat adjustment triggered by the user management can be interrupted by the manual seat adjustment and vice versa Naturally both modes have to be able to interrupt one another This is realised by a rather 100 CHAPTER 6 ASCET SD simple logic applied between the implemented classes A
274. s no other actors and communicates with the right TSG the left door the mo tors for un locking the doors both radio keys the battery and the car CANBATT ZUEND COM FrikSeider T9G R COM Figure 12 4 Structure of actor class a TuerRiegelung The behaviour of the TuerRiegelung has been modelled with a total of eight hierarchically ordered state machines TOP Level 1 state machine contains the WillEntriegeln 2 and WillVerriegeln 3 state machines The WillEntriegeln state machine 2 contains the CheckVorraussetzungen 4 and Entriegeln 5 state machines The same happens with the WillVer riegeln 3 state machine which contains the CheckVorraussetzungen 6 and Verriegeln 7 state machines and additionally a Wait 8 state machine within the CheckVorraussetzungen 6 state machine Two main functions have to be implemented lock and unlock the doors Both of the actions have different and complex conditions they have to ful fil in order to be done So to have a clear structure in the model we made use of the hierarchy and divided the behaviour into two the locking and the unlocking part 242 CHAPTER 12 TRICE TOOL BY PROTOS SOFTWARE GMBH Depending on the input messages the TV receives one of the two actions will be started WillEntriegeln 2 Desire to Unlock or WillVerriegeln 3 Desire to Lock Some of the input messages set predefined extended state variables to a value For example if the message key_abschliess
275. s positive and negative aspects Strengths ASCET SD offers very good possibilities of designing modu larly Functionality can be encapsulated in hierarchical classes or state machines Classes specified once can be instanciated wherever their functionality is required The reuse and the hierarchical structuring leads to a quite clear and readable model Furthermore we want to mention the several description techniques which enable to find a suitable one for many various modelling prob lems The modelling of the functionality can be done completely indepen dent from the target platform Using Target Integration Packages the executable code for models is generated by the automatic code gen erator ASCET SD supports all market relevant micro controllers ASCET SD offers two ways of validating a model Offline and Online Experiments The Offline Experiment runs on the host that simulates the time flow For testing the model in real time it has to be exe cuted on the experimental system ES1000 2 This system simulates the target platform and allows to test nearly under real conditions Therefore the tool is very suitable for Rapid Prototyping Other strengths of ASCET SD are the automatic document generator and the voluminous manual Weaknesses ASCET SD also has some weaknesses and features that could be improved Changes in the model sometimes are not immediately updated by the tool and have to be done manually The standard
276. sages are global variables with access rights that are used for data exchange The con 80 CHAPTER 6 ASCET SD cept of message exchange is also anchored in the real time operating system ERCOS FF When the processes are scheduled then the OS guarantees the consistence of the messages There are send receive and send receive messages to let modules communicate among each other In a model there are three types of interfaces available messages methods and input output variables Messages are the interfaces of the modules As aforementioned they are used as interfaces to other modules but they also define the communication channels to exter nal components Therefore all external signals sent and received have to pass these interfaces Methods and input output variables are only used to determine in ternal interfaces Classes and state machines can communicate over these internal interfaces with their parents Modelling aspects Using the provided notations allows to model the aspects structure behav ior interaction and interfaces The following gives a comprising overview of the notations classification e Structure project modules classes state machines e Behavior block diagrams ESDL C state machines e Interaction messages e Interfaces messages methods input oupt variables Type of notation The tool offers two representation types textual and graphical ESDL and C are specified textually whereas the block di
277. seat adjustment is a bit more complex than the user management therefore it contains more different classes than the user management A very essential class is the comparator class It compares the desired position of the seat transmitted by the user management with the real position of the seat If the adjustment of the seat is started by the user management buttons and not by the radio transmitter the calibration should follow a certain priority If on the other hand the trigger of the action was the radio transmitter this priority should be ignored Both behaviors are modelled with their own class As the seat can be adjusted manually the component becomes much more complex These manual inputs have to be analysed They are correspondingly handled by a class respectively by the instances of this class For every axis there is an input so this certain class is needed five times The specification requires that in every case the last user action must be executed So the manual adjustment has to be able to interrupt the automatical adjustment activated by the user management and vice versa Naturally every component has to be able to interrupt itself For example if during the seat calibra tion by the user management the desired seat position changes the 94 CHAPTER 6 ASCET SD user management seat adjustment current osition Figure 6 14 Structure of Module 3 Figure 6 15 Part of the block diagram for the priority
278. shing the turn signals This is done too by sending a message on the CAN Bus 118 CHAPTER 7 AUTOFOCUS 5 LowBatt owBattRegPos Pa 6 LowBattmF 5 buttonpte 5 ugk xe PosBackward 5 button released g 5 buttgmfressed detected 5 button pfegsed detected Agor open ro interrupt 5 button released br door open ro interrupt 5 move hackward lon pre 5 gsed detected 5 button pregsad detested 5 moye f nwerd 5 button pr ssedwetected 5 move fofward Figure 7 6 The automaton that is responsible for processing movement commands to a seat motor 7 4 0 Seat Control The Seat Control component consists conceptionally of three parts One part for the control of the user commands received from the button for the man ual control of the seat adjustment one part for the control of the position adjustment requests from the user control part and one part that executes the seat motor control and sends the commands to the seat position adjust ment motors Fig 7 5 The Seat Control component receives input messages from the 2 Plugs and the CAN Bus It also receives messages from the User Control component that contains position data for a requested seat position adjustment It sends messages to the Plug 2 that control the seat movement motors as well as an error message that is send to the output merger for the CAN Bus The movement request commands have to be checked for t
279. small This way one can only see parts of a big signal This can be very confusing when the signal consists of many Variable of the same type Debugging Features In the simulation process the cycle time can be ad justed This way we were able to view the simulation at the speed desired During the interesting parts we switched to the single step mode to be sure that we caught all the details In the simulation the state of the whole system including active au tomaton states and values of variables and channels can be viewed This way we always had a good overview on how the entire system reacted on our inputs Also the coverage of the system test can be seen here If a channel passes a message it changes the color This way it was easy for us to see which parts of the system had been cov ered by our test case It is also possible to take a look at the signals that had been send though a channel This helps to ensure a coverage of the different port values This kind of graphical debugging is very suitable for error tracking Unfortunately it is not possible to elimi nate the errors right here Even for the smallest error the simulation has to be stopped and one has to go back into the design view Testing We used Test Vectors during the simulation We retrieved them by saving the input output data after a successful test Then we were able to reuse them and to run the same test all over again This way one can ensure that the system stil
280. soon as it seems useful a first prototype can 227 228 CHAPTER 12 TRICE TOOL BY PROTOS SOFTWARE GMBH be transferred over to the target system and tested Testing and mon itoring is possible during the development but also during service and maintenance in the running application Documentation The Trice documentation is very good for an initial intro duction on how the tool works It contains an user guide reference manual and some tutorials as well as other information such as a description of the modelling lan guage the protos Virtual Machine etc The tutorials are very use ful in order to get a first acquaintance of the modelling technique in general The user guide is practical because it provides with general information about various aspects of usage ranging from theoretical background to practical issues However it does not cover every as pect into its maximal detail so that some issues had to be clarified with the tool developers For more information about the graphical user interface the reference manual is of great help because it con tains a detailed description of all editors dialogs and browsers of Trice basic appearance elements of the workspace output bar tool bars data classes protocol classes actor classes The information contained there is also reachable as online help Usability We were very satisfied with the usability and the user interface of the tool It is well structured and self
281. st our system in a better way we build an en vironment around the system The environment simulates the signals that are sent from the three connectors to the Tuersteuergeraet During simu lation with the model verifier you only have to enter signals which the car driver triggers The results of these simulations allow us to discover some bugs which led to improvements of the system 11 3 2 Applied Process Support Development operations All graphical views i e the tree window and all diagrams provide full graphical modeling and modifying as known from modern MS Windows OSs and applications The tree see Figure 11 9 view permits similar modifications that the MS Explorer pro vides like drag and drop The diagrams can be edited using tool bars drag and drop copy and paste similar to MS Powerpoint or Visio To visualize elements of the model tree graphically you can simply drag and drop them to a appropriate diagram If the element is not suitable for the diagram e g if you want to drag a state into a class diagram you cannot drop it Reverse engineering With Telelogic Tau you can generate some UML ele ments out of C C header files of the source code if the code fulfills some conditions Telelogic defined a fixed set of transformation rules from UML 2 0 to C C Therefore C C code needs to be compli ant with these rules In particular header files generated by Telelogic Tau 2 0 can be imported and converted into a UML mode
282. sys tems can be used to develop the model of controller software for comfort electronic in the automotive domain The applied tools are e ARTISAN RealTime Studio by Artisan Software e ASCET SD by ETAS GmbH amp Co KG e AutoFOCUS by Technische Universitat M nchen e MATLAB StateFlow by The MathWorks Inc e Rose RealTime by Rational e Rhapsody in MicroC by I Logix Inc e Telelogic Tau G2 by Telelogic Inc e Trice Tool by Protos Software GmbH With each tool a model of a controller software module was developed based on a given textual requirement specification The requirement spec ification of the controller was taken from a revised version of a controller specification provided by F Houdek Daimler Chrysler AG Each tool was applied by a group of three to four students the students had no experience with the applied tool After receiving an initial training in using the tool the students were given three months to develop the model The model of the controller software was developed in two steps first step simplified three axis seat control second step five axis seat control to add the aspect of specification reuse Finally the application of the tool was assessed by each team using a common questionnaire This report presents the results of these questionnaires in a detail and summarizes them to give a state of the art impression of CASE tools for embedded systems Building on this summary it sketches what properties 9
283. systems and for its validation and verification after the developing process Then we have data type definitions DTDs see Section 7 4 Model of the Controller which can be defined in JAVA or QUESTF When starting a new model the developer has the choice of which programming language to use If you take Java a partial set of basic types of the Java programming language is available for typing but user definded types are not allowed Therefore the models are sometimes difficult to understand QuestF as a functional language allows such types besides Bool Float and Integer by means of data constructs so that channels and ports can have types which are self explanatory User defined aux iliary functions can also be built in QuestF and even constants can be defined The concept of the DTD using QUESTF is very powerful and gives the experienced developer a very powerful instrument at hand to develop own data type and correspond ing functions for the design of the model At last AUTOFOCUS provides the concept of state transition dia grams STDs see Section 7 4 Model of the Controller which is similar to state charts diagrams known from the UML mod elling language Each STD can be assigned to one or several SSDs In such diagrams there are different states which can be initial final both or just regular states Beginning with the initial state another state can be reached with a transition A transition takes different arguments w
284. t ein Blinkzyklus mit 54 100 DURATION Leuchtzeit und 46 100 DURATION Dunkelzeit o Weitere Botschaften die w hrend Leucht oder Dunkelzeit eingehen werden ignoriert 15 o Erst nach Ablauf eines Blinkzyklus werden weitere Blinkbotschaften bearbeitet e Botschaft 0x28c o Die Signale M POS 1 und M POS 2 werden gesendet wenn der Benutzer einen Funksender verwendet o Die anderen Botschaften sind f r den Einsatz eines Fahrerassistenz Systems vorgehalten momentan nicht verwendet e Botschaften Ox6fe und Ox6ff o Diese Botschaften werden vom Kombiinstrument ausgewertet im Fehlerfall kann eine entsprechende Warngrafik im Kombi Display angezeigt werden 16 5 Funktionen In den nachfolgenden Abschnitten finden sich die detaillierten Anforderungen an die Systemfunktionen des TSG F r jede Systemfunktion findet sich eine Beschreibung der Systemein und ausg nge die Beschreibung des Verhaltes sowie Angaben zum Initialisierungsverhalten Die Systemein und ausg nge sind wie folgt gekennzeichnet e Sl x Eingang von Stecker S1 siehe Abschnitt 3 2 1 e S2x Eingang von Stecker S2 siehe Abschnitt 3 2 2 e S3x Eingang von Stecker S3 siehe Abschnitt 3 2 3 e CAN x CAN Signal siehe Abschnitt 4 5 1 Allgemeines Verhalten Eing nge e Zustand Fahrert r S1 T_OFFEN e Zyklische CAN Botschaften CAN KL ISKEY CAN KL_15RADIO CAN KL 15 CAN KL 15START CAN BATT CAN FCODE T0 CAN FCODE TI Ausg nge Zyklisch gesende
285. t was one of the big points in the tool Trice supports this way of developing or modeling a system So it can be used for rapid prototyping as well as real development 12 4 CONCLUSION 237 Restructuring The application architecture could be adapted by using the component drag amp drop feature which adjusts the communication and interactions between the actors and their sub components properly There is the possability to include a new layer in the application very easily by using the described mechanism of the tool The restructor ing things are also possible for the state machines using drag amp drop 12 4 Conclusion The Trice Tool has a powerfull IDE and is very stable Its modelling ap proach technique permitted us to represent our model on a high abstrac tion level So our model is platform independent and we did not need any specific knowledge for the final implementation platform Therefore the Trice Team offers further assistance The usability of the tool is very intu itive and there is no need for a deeper understanding of the method to start modelling We followed the principle of learning by doing and it resulted very good for us We were also very satisfied with the code generation as the resulting code is small in size and well documented Although we were very satisfied with the tool there are some aspects that did not fully convince us or were missing For example hotkeys are only partly implemented When modelling a
286. ta types The activities are able to contain other activities control activities or state charts An example activity chart is depicted in Fig 9 6 State charts Rhapsody s state charts illustrate functionality of em bedded systems and are made up of states and transitions These charts can be seen as state automata which can execute actions dur ing staying in a state or during the transition of one state into another For an example state chart see Fig 9 7 The state chart offers extended concepts hierarchy parallelism and history states Hierarchy allows the developer to interleave states or charts so he can start the developing process at the highest level and go into de tails more and more The possibility of covering an automata with a 9 2 MODELLING THE SYSTEM 161 INFORMATION_FLOW Figure 9 6 Example activity diagram SUPER_STATE STATE_1 STATE_4 STATE_S Figure 9 7 Example state diagram 162 CHAPTER 9 RHAPSODY IN MICROC higher ranking state offers the chance to design well structured and clearly arranged projects Parallelism is also offered in Rhapsody This means that two or more states can be executed concurrently In Rhapsody parallelism is achieved by so called and states pictured by state machines separated by a dashed line Beyond it history states serve for remembering in which state an au tomata has been before it was left because of switching of a higher ranking transition On return th
287. tance like a wizard for helping especially new users in designing a model for the first time is not included in RiMC More over the support of context dependent process activities is not pro vided in the tool But there are design guidelines available as PDF files Consistency ensurance mechanism

INSTITUT F&uml;UR INFORMATIK CASE Tools for Embedded Systems

Contents

INSTITUT F¨UR INFORMATIK CASE Tools for Embedded Systems