UML SPECIFICATION BASED FAULT DIAGNOSIS IN EMBEDDED SYSTEMS

Transcription

1 UML SPECIFICATION BASED FAULT DIAGNOSIS IN EMBEDDED SYSTEMS F. Matzke 1, V. Vasyutynskyy 2, K. Kabitzsch 2 1 Océ Printing Systems GmbH, Siemensallee 2, D Poing, Germany, fax: , frank.matzke@ops.de 2 Faculty of Computer Science, Dresden University of Technology, D Dresden, Germany, fax: , vv3@.inf.tu-dresden.de, kabitzsch@.inf.tu-dresden.de Abstract: A diagnostic method based on UML specifications and the appropriate diagnostic system are presented. The method interprets UML behaviour diagrams in order to use them for recognising anomalies in monitored data streams. It is especially intended for finding out communication anomalies in embedded systems. The implementation of the diagnostic system was tested successfully at Océ Printing Systems GmbH. Keywords: fault diagnosis, UML, specifications, sequences, monitoring. 1. INTRODUCTION The main goal of this work was to detect the effects and the causes of faults. In contrary to tests[1], where a lot of automatic methods exist [2], the diagnostic methods[3] lack automatic working tools. Therefore, the development was concentrated on building a The next range of problems is the special environment of embedded systems with the following features: 1. There is no visual interface. 2. The behaviour is non deterministic. 3. There is a high amount of communication between heterogeneous hard- and software components 4. Real time demands have to be regarded (including the probe effect of the diagnosis itself). These points make it difficult or often impossible to use common debugging methods[4]. The experience during diagnosis at Océ Printing Systems and the statistical evaluation of the internal error database showed, that the following kinds of faults lead to highest costs: 1. Sporadic faults 2. Timing problems 3. Communication problems One general characteristic of three kinds of errors mentioned above, on which the article is focussed, is the difficulty to reproduce the problems and to use classic debugging methods. A better way is to use offline diagnosis based on recorded log data (traces). Traces contain information about internal events, states and/or communication activities between components in their chronological order. Trace based manual diagnosis is the prevalent diagnostic method at Océ Printing Systems GmbH. The problem is that potentially traces could contain high amounts of data, so the analysis of the data would require a long time. Therefore filtering and triggering methods [5] are used to limit the amount of data in the traces. The disadvantage of these methods is that important data may get lost. Therefore a method was developed, which can provide the diagnostic work to be carried out partly automatically to analyse large amounts of data in acceptable time, thus the necessary diagnostic knowledge is needed only during the adjustment of a Prerequisite for the use of automatically functioning diagnostic methods is the knowledge about the required system behaviour, to be able to compare it with the real one. The behaviour of a system is defined in the specification. The ideal case is, when the specification can be directly used by an automatic diagnostic tool. In reality, the specification must exist or be converted in computer-readable form. All the mentioned leads to the development of a specification based diagnostic method. It is especially targeted to find out communication problems and sporadic failures. Communication problems can be easily checked according to UML Sequence diagrams [6][7]. Also problems caused by deviations from the specification in the running program can be found via UML activity diagrams. This is of great value concerning sporadic problems, because the automatic diagnosis makes it possible to find a cause fast. The diagnostic method helps to get closer to the cause of a problem automatically, as the part of the specification, which is used for diagnosis, allows.

2 This paper describes the diagnostic tool Extrakt (Dresden University of Technology) in combination with the UML-Analyser VisErr (Océ Printing Systems GmbH). These programs contain methods for automatic analysis of traces based on UML behaviour diagrams. The traces are analysed iteratively to recognise deviations from the specified behaviour. Section 2 illustrates the structure, the working principle and enviroment of diagnosis system. In section 3 the technique will be described, which allows to use UML diagrams for diagnosis purposes. Section 4 presents the methods to recognise unusual (abnormal) events and states. 2. DIAGNOSTIC METHOD The common manual way needs a lot of time and well qualified and expensive troubleshooters for diagnosis. The difficulty lies in the amount of data which has to be checked. The manual diagnosis is a boring job where details can be easily overseen. The specification defines the structure, the functionality and the limits of a software product. The specification can be in oral, written or computer treatable form, it is created before implementation and may be changed for new needs. In general, every diagnosis of a software product must be based on its specification. A product is only a subset of a specification. When diagnosis is done manually, the gap between specification and implemented software has to be considered. An automatic diagnosis is limited in that way, because it is difficult to carry out diagnosis inside of this gap. The knowledge of the developer would have to be implemented, which would be costly, and in the end it couldn t be regarded as product standard. It is much easier to use the specification, especially if it has the proper format. Therefore the goal is to develop a tool, which restricts the area, where a fault potentially is hidden. This is necessary to isolate the fault and to minimise the cost of the diagnosis. The used diagnostic technique is based on the so called monitoring [8]. This method uses recorded data in a device to analyse the behaviour of the system post factum. The data consisting of information about events, states or communication are recorded in chronological order inside of the device or with external tools. Before the diagnosis can be done, the tool must have access to a knowledge base that describes correct or possible incorrect behaviours of the device. Therefore the specification or parts of it are included in the knowledge base. The diagnostic system uses the specification rules inside the knowledge base to control the diagnostic process. The XMI-Analyser reads UML documents created by an UML drawing tool which supports the XMI (XML Metadata Interchange) standard [6][9][10]. First it selects the supported types of UML diagrams for diagnosis. These diagrams are used by the analyser to create rules for the knowledge base. Data evaluation Interpretation Statistical functions Data converter Trace files Knowledge base XMI-Analyser UML-Tool Specification Embedded System Fig. 1 Architecture of diagnosis system The first part of the main diagnostic process is to convert the trace data into the suitable format to work on. If needed, statistical functions can be applied on the working database during the next step. During the interpretation phase, the search for anomalies in the trace is done. The found information is evaluated during the next step. The results of the evaluation can lead to an iterative use of the described steps with the resulting data. This allows to use abstract rules in the knowledge base. This method is suitable to find errors efficiently, which have sporadic behaviour or are transient, i.e. they appear or are detected very seldom and disappear quickly. Experience shows that trace based diagnosis also works effectively for most kinds of software problems. 2.1 USAGE OF VISERR AND EXTRAKT This section explains what has to be done to find a failure with VisErr and Extrakt. We should consider the following requirements before the diagnosis starts: The specification of the observed system has to be created by an UML drawing tool (Tests were done with MagicDraw UML 5.5, [11]). VisErr takes the UML specification and transforms it in sequence rules. For each version of the observed system this transformations have to be done once. The created sequence rules are used to steer the diagnosis and they can be used as long as the specification is valid. Diagnosis proceeds then in the following steps: A failure or undesired effect is noticed at the observed system during tests or by the customer. If the monitoring isn t done permanently or the level of abstraction, which defines the sort of data to be monitored, has to be adjusted, the failure has to be reproduced with the correct monitoring.

3 The monitoring data (trace) are transferred to the If necessary, the trace has to be converted into a format that Extrakt supports. Rules for proper process sequences are delivered to Extrakt. The actual analysis is started. Now the correct parts can be seen in a spread sheet or in graphical chart form. This makes it possible to find out the area in the trace where cause of the failure lies. The location of the failure cause in the source code now should be analysed and corrected by manual operations to close the gap between specification and implementation. 3. SPECIFICATION ANALYSIS UML is actually the most widespread formal language respectively of notation to create specifications [6][7]. UML is a formal language that offers different sorts of diagrams to specify a system from different points of view. Together with the OCL (Object Constraint Language [6]), which can be used to add constraints to the diagrams, a very powerful specification language is build up. There are already existing diagnosis methods based on UML sequence diagrams. But they don t use the diagrams to compare them with the real behaviour of the specified device. Instead of that, the observed software is forced to generate traces in form of UML sequence diagrams [12][13], which seems to be an improper use of UML, because the resulting diagrams contradict the specification purpose of UML. SDL-Diagrams [14][15] were used for automatic diagnosis as well [16], which were focussed on time failures, whereas the presented tools concentrate on behavioural failures. UML offers three categories of diagram types - use case diagrams, class diagrams, behavioural diagrams and implementation diagrams. The highest potential for automatic running diagnosis can be found in the category of behaviour diagrams (sequence diagram, collaboration diagram, state diagram, activity diagram). With these diagrams it is possible to describe the behaviour of a system in a very detailed way. The way the diagrams are describing the software flow and the communication is congruent on the abstraction level of the diagrams to the way software source code is structured. Therefore, a result near to the cause of faults can be expected with the usage of this kind of diagrams for diagnosis. UML itself wouldn t be applicable for automatic diagnosis, because it s only a notation. To support the usage of UML diagrams with different UML tools, the XMI format was introduced. XMI documents contain information about the structure of UML diagrams in a formal notation. The remained section shows, how sequence and activity diagrams can be used for diagnosis. The prerequisites are: To simplify diagnosis and abstraction the origin of each trace entry should be recorded. In the UML diagram the information about events, states or communication should be integrated, to be able to compare the real device behaviour with the defined one. 09:57: D0200 Print-Job received 09:57: Rendering begins 09:57: D0200 open_image_doc 09:57: rasterize_data 09:57: Rendering ends 09:57: Print-Job committed Fig 2: Example - Trace The method to analyse a XMI document is done in the following way: A document is searched for diagrams. Each suitable diagram is parsed and converted into a sequence, which can contain logical operations. A sequence is a rule, which defines the chronological order and content. The sequences are transferred to the knowledge base. UML behaviour diagrams can be separated in two groups with similar characteristics: sequence diagram, collaboration diagram state diagram, activity diagram The diagrams in each group differ mainly in the way they are used. Therefore, parsing behaviour diagrams can be done by two methods which are shown in the following sections: 3.1 Analysis of sequence diagrams Sequence diagrams are mainly used to specify the communication behaviour. The following steps are done during the analysis of a sequence diagram: 1. Loading XMI document and searching for sequence diagram. 2. Search for classes which are used in the diagram. The classes define the origin of a trace entry. This information is used to check the proper origin and to separate concurrently generated trace information. The class names are stored in a list. 3. Search for transitions between classes. The transitions are stored in a list sorted by time. Every list entry contains the sending class, the receiving class and tagged values. To be able to check the correct behaviour of the device, a tagged value must contain the event / state / communication information admitted from the UML diagram. 4. A scenario for Extrakt is created. A scenario consists of a set of filter rules and sequence rules. Each tagged value entry is treated as event provided it has the corresponding origin which is

4 defined by the sending/receiving class. The list created in step 4 is used to create a sequence of events. PARS_SEQ 1: {INFO=Print-Job received} 2: {INFO=Print-Job commited} EES Event A Event B values. At branches the sequence is split up into the main sequence and sub sequences which are referenced in the main sequence. The sub sequences are set in relationship by an OR operator[5]. The paths starting at the branches are treated in the same way to create sequences recursively. 7. Composing of the scenario (compare sequence diagram). {INFO=Rendering begins} Fig. 3 Example - Sequence diagram The analysis of the UML sequence diagram example in fig.3 would have the following result: {DataType == IMAGE_DATA} Prepare Image {INFO=open_image_doc} Event A {DataType!= IMAGE_DATA} Event C Events A = Print-Job received and origin: PARS_SEQ or EES B = Print-Job committed and origin: PARS_SEQ or EES Sequence C = A Seq B A, B: Event C: Sequence Seq: Sequence operator [5], which assigns that event B should follow event A. 3.2 Analysis of activity diagrams Activity diagrams are used to display the software flow in a structured form. Parallel behaviour is also supported. Therefore it is well suited for embedded systems. Special prerequisite is that cyclic data structures (the same state or transition could be reached more than once) are not available and condition terms can only be considered indirectly. This means that the branches are supported concerning the sequence of events, but the condition term, which is responsible for the used path, is not checked. The analysis of activity diagram consists of the following steps: 1. Loading the XMI document and search for activity diagrams. 2. Searching for all states in the diagram. The states are stored in a list together with the corresponding tagged values. Decision, Merge and other UML objects are also treated as states. 3. Search for transitions. All transitions together with their tagged values are stored in a list. 4. Connecting transitions and states. The list of states (step 3) is enhanced according to the transitions list (step 4) by linking the state-objects together. The result is a cycle free state machine. 5. Searching fo all start states. 6. Beginning with the start states the sequences are build. Following the linked states and transitions, the sequences are build according to the tagged Event B Render Page {INFO=rasterize_data} Fig. 4 Example - Activity diagram {INFO=Rendering ends} Event D Using the described procedure with the example in figure 4, this would result into the following scenario: Events A = Rendering begins B = open_image_doc C = rasterize_data D = Rendering ends Sequences E = B Seq C Seq D F = C Seq D G = A Seq (E OR F) A, B, C, D: Event E, F, G: Sequence Seq, OR: Sequence operators [5] G is the superior sequence for diagnosis which is assembled by sub sequences. If the assignment of the sequences to the diagrams is finished, it is possible to use several diagrams to create an assembled data structure. By that way it is possible to use higher abstraction layers to get better overview. The generated scenarios will be much more complex. 4. FAULT DETECTION AND INTERPRETATION Extrakt supports the diagnosis through automatic inspection of traces produced in embedded system. It uses the rules generated in the way described above to check, if they have been correctly executed. Diagnosis may proceed in two ways: fault detection and anomaly detection. In first case the known faults described by UML-diagrams are sought (for example, incorrect process). The positive search result shows that the fault happened in certain time interval and under certain conditions. To find the exact cause of a fault, the fault prehistory must be

5 analysed, among others through the anomaly detection. The second way uses the rules, that describe normal system behaviour, to find out possible deviations. These anomalies may indicate the fault or admissible process deviation. Obtained information is used by troubleshooter for fault isolation or correction of behaviour model (for example, setting new constraints). The following criteria can be used for anomaly indication: violation of process rules, unusual time behaviour (i.e. too long processes). Search results are presented in comfortable way: diagrams, tables, time lines (s. (fig. 5-7). The troubleshooter can easily switch between different views to achieve better understanding of the system behaviour. Fig. 5 Normal behaviour Fig. 6 Defect sequence found Fig. 7 Defect activity found 5. CONCLUSION Defect activities Defect sequences The presented tools VisErr and Extrakt make it possible to support the diagnostic work in an embedded system in an efficient and effective way. The tools especially appropriate for faults that don t appear very often (sporadic faults), but which result in high costs. These tools worked satisfactory during tests at Océ Printing Systems GmbH. But the development of these tools has just begun and there s a certain room for improvements. The next step of the VisErr development is to support collaboration diagrams and state diagrams. To provide that, it is necessary to support cyclic data structures (section 3.2). A method to transform cyclic data structures in sequence was already formulated, but not implemented yet. An important enhancement would be also to support the OCL in UML diagrams. This would allow to provide a much more powerful diagnosis, because logical conditions could be checked. Anomalies from specified value margins and timings could be found. These enhancements would allow to get closer to the complete use of UML specifications for diagnosis and to get a larger range of detected failures. REFERENCES [1] Thaller G. E., Software-Test, Verifikation und Validation, Hannover: Verlag Heinz Heise GmbH, ISBN , 2000 [2] Dustin E., Rashka J., Paul J., Software automatisch testen, Original English language title: Automated Software Testing, Heidelberg: Springer Verlag, ISBN: , 2000 [3] Hatton L., Exploring the Role of Diagnosis in Software Failure, IEEE-Software, July/August 2001, pp [4] Cleve H., Zeller A., Automatisches Debugging, Universität Passau, Lehrstuhl für Softwaresysteme [5] Thane H., Monitoring, Testing and Debugging of Distributed Real-Time Systems, Doctoral Thesis, Royal Institute of Technology, KTH, Stockholm, Sweden, 2000 [6] UML-Spezifikation, OMG Unified Modeling Language Specification, Version 1.4, September 2001, [7] Fowler M., Scott K., UML-Distilled, Second Edition, Boston: Addison-Wesley, 2000 [8] Peters D. K., Parnas D. L., Requirements-Based Monitors for Real-Time Systems, IEEE Transactions on Software Engineering, Vol 28, No. 2, February 2002, pp [9] XMI-Spezification, OMG XML Metadata Interchange (XMI) Specification, Version 1.2, January 2002 [10]Grose T. J., Doney G. C., Brodsky S. A, Mastering XMI, OMG PRESS, New York: Wiley Computer Publishing, 2002 [11]MagicDraw UML, User s Manual, Version 5.5, No Magic, Inc, [12]Canditt S., Grabenweger K., Reyzl E., Tracebasiertes Testen von Middleware, Java- Spektrum, 3/2001, sigs, 2001 [13]Windpassinger H., Echte Tests, Testen im Embedded-Umfeld, Objektspektrum, sigsdatacom, 2/2002, pp [14]SDL Forum Society [15]Fischer J., Holz E., v. Löwis M., Prinz A., SDL- 2000: A Language with a Formal Semantics, Humboldt-University Berlin, Institut für Informatik, 2000 [16]Pekilis B. R., Seviora R. E., Detection of Response Time Failures of Real-Time Software, Proceedings of the 8th International Symposium on Software Reliability Engineering (ISSRE 97), 1997, pp