Architecture-Driven Platform Independent Deterministic ∗ Replay for Distributed Hard Real-Time Systems Holger Giese and Stefan Henkler Software Engineering Group, University of Paderborn, Warburger Str. 100, D-33098 Paderborn, Germany
[email protected],
[email protected]
ABSTRACT Distributed hard real-time systems have become a major component of many advanced technical products. Means to ensure their proper quality are thus of paramount importance. To ensure high quality software, besides preventive means also cost-effective techniques for defect removal are important. The later activity in practice includes testing in order to detect failures, subsequent diagnosis in order to pin down the observed failure to a defect, and finally the proper removal of the defect. In this chain of activities, finding the cause of a failure is often a rather difficult and longwinded undertaking. In the domain of embedded real-time systems the problem is even harder than in a standard environment because of the real-time behavior and hardware heterogeneity (development vs. target platform). Both renders the deterministic replay of faulty behavior a hard problem which today can only be addressed when a substantial amount of additional monitoring hardware is added to the system. The paper proposes to minimize the required additional hardware using an architecture-driven approach which exploits the high-level information available at the architectural level in order to achieve platform independent deterministic replay for distributed hard real-time systems at relative low cost.
1.
INTRODUCTION
Distributed hard real-time systems have become a major component of many advanced technical products. Thus the quality of their software has become one major concern during the development, as malfunctions of such systems are often safety-critical or can result in great financial losses. Thus, in practice models of these systems are extensively simulated and the resulting systems are rigorously tested to ensure the correct and safe operation of the software. Improving the quality includes besides preventive means also cost-effective techniques for defect removal. The later activity in practice includes testing in order to detect failures, subsequent diagnosis in order to pin down the observed failure to a defect, and ∗This work was developed in the course of the Special Research Initiative 614 - Self-optimizing Concepts and Structures in Mechanical Engineering - University of Paderborn, and was published on its behalf and funded by the Deutsche Forschungsgemeinschaft.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ROSATEA ’06 July 17, 2006, Portland, Maine, USA Copyright 2006 ACM 1-59593-459-6/06/07 ...$5.00.
finally the proper removal of the defect. In this chain of activities finding the cause of a failure is often a rather difficult and longwinded undertaking. In extreme cases it might even happen that the cause of a manifested failure is not detectable at all [27]. In the domain of distributed hard real-time systems the problem is even harder than in the standard case, because of the real-time behavior and the heterogeneity, which results from the fact that the software often must be developed on hardware which differs from the hardware which is later employed as target platform. The target hardware is often not known or not yet available in the early phases of development. Therefore, the software is usually simulated together with an emulated environment as well as hardware. The results of these different simulation models and different hardware settings are employed to detect and remove faults in the models and code as early as possible. However, due to the incomplete nature of testing different failures may show up in the different simulation and test stages. The real-time interaction of the systems also renders their simulation a difficult task. Depending on the considered simulation stage (cf. [6]), the effort to achieve meaningful simulation results even though not all technical details of the target platform are taken into account can be rather high. Most distributed hard real-time systems are also embedded systems. Due to the severe resource limitations for these systems and the real-time interaction of the software with its environment, the support for testing, observation of relevant values, and diagnosis of the software on the target hardware is rather restricted [2]. Additional test hardware has to be employed to avoid probe effects and identical hardware is required to be able to reproduce observed behavior in additional diagnostic runs [25]. The outlined problems render the deterministic replay of faulty behavior a hard problem which today can only be addressed when a substantial amount of additional monitoring hardware is added to the system. In addition, an existing event log can usually only be employed on the same hardware and software platform to replay an execution. Therefore, some authors even claim that today’s approaches cannot achieve deterministic replay if different hardware is used [26] arguing that such complex effects like scheduling, CPU speed etc. cannot be correctly emulated for real systems. Today an open and flexible software architecture is often missing in the domain of distributed hard real-time systems (cf. for the automotive domain [17]). Consequently, the proposed concepts for debugging and deterministic replay are only exploit the structuring of the hardware or operating system but not the software architecture level. Initiatives such as AUTOSAR1 exists which try to define a platform for the software components which enables the architecture-driven development of distributed hard real-time 1
www.autosar.org
systems where components from different suppliers and vendors can technically interoperate. Therefore, it seems promising to look for better solution to achieve deterministic replay which exploit the additional high-level information which is present in architectural models. The paper proposes to minimize the required additional monitoring hardware using an architecture-driven approach which exploits the high-level information available at the architectural level in order to achieve platform independent deterministic replay for distributed hard real-time systems at low cost. The proposed solution is innovative as it addresses the diagnosis part to improve the software quality in the outlined test, diagnosis, and fix approach, while the existing work only exploits the architectural models to address the testing or the testing process: In [24] it is shown that the architectural specification of a system helps to effectively test at the architectural level by detecting architectural defects earlier in the software development life cycle. An approach for using software architecture for code testing is presented in [21] which selects the relevant test cases for an implementation taking the dynamics of the software architecture described by labeled transition systems into account. Other work includes the derivation of integration test plans from architectural descriptions [4] as well as software architecture-based regression testing [22]. We will at first review the current state of the art for deterministic replay for distributed hard real-time systems in Section 2 and outline the resulting research challenge. Our concepts for the platform independent deterministic replay on the architectural level follows in Section 3. As prerequisites for its concrete realization we then introduce the employed model-driven development approach and its architectural elements in Section 4 before we describe the underlying run-time framework and its potential for instrumenting the applications in Section 5. Our realization concepts for the integration of deterministic replay into the beforehand outlined run-time framework follows in Section 6. In Section 7, the evaluation results obtained so far are outlined before we sum up the paper and provide an outlook on planned future work.
2.
STATE OF THE ART
In order to be able to pinpoint a failure down to a defect, it is usually not sufficient to do a single execution of the program and analyze its result. This would only be enough if besides the input and output of the program also the complete sequence of intermediate states was recorded. This is not useful and also often not feasible even for small applications. Instead the determinism of the algorithmic program behavior is exploited to reproduce the faulty execution sequence. While such as deterministic replay is trivial in the case of sequential non real-time programs which do not interact with the environment and do not refer to time, things become tricky in more complex cases where real-time or concurrency effects can result in a somehow non-deterministic behavior of the system under consideration.
2.1 Hard Real-Time Systems In hard real-time systems the correct behavior depends on the correct computation of the results as well as the timely delivery of the results. Therefore, the programs do not operate independently of time and the same timing is required during the reference execution and during the repeated execution to exclude that the programs behave differently. Because of resource limitations and the lack of debuggers for embedded target systems, diagnosis is typically done on host systems. As different or additional hardware can also result in a different behavior [26], the observations are not necessarily valid for
the target hardware. For example, it is really hard to achieve the same timing on different systems because of different clock drifts and the lack of synchronization [18]. In the case of software monitoring, instrumentation of the source code is needed to observe the relevant events for deterministic replay. For the considered systems lots of data is needed. This includes all timing, all external events (messages), and all scheduling events like thread switches. During the early development phases, where the software is executed on the host system, this is typically no problem. During the later phases, however, the lack of resources on the target system can result in severe problems. Due to this limitation probes for monitoring relevant events must often be removed or strictly limited for the later development phases. These different probes can then result in different operation times and timing and thus in different behavior. This effect is called the probe effect [20]. To avoid the probe effect, additional hardware is needed [29]. If software-based monitoring is used, the effect of additional probes has to be eliminated. Because monitoring is often relevant during the whole life cycle of embedded systems, a popular technique is minimizing the relevant events and keeping the probes up during development and operation (cf. [11] and [12]).
2.2 Concurrency & Parallelism There are a number of sources of non-determinism relating to concurrency that render deterministic replay a problem. Due to the operating system scheduler, concurrent processes can influence each others timing (pseudo non-deterministic scheduling effects). In case of networking, different message transportation times due to non predictable network protocols may yield the different output on repeated execution (pseudo non-deterministic network behavior). Additionally, message losses or the reordering of messages in networked systems could result in a different repeated execution. Due to these characteristics of concurrency and parallelism, deterministic replay is more complicated to achieve for these systems. LeBlanc [19] introduces instant replay of parallel programs. Today instant replay or deterministic replay is a widely used technique in the domain of debugging parallel programs. However, this approach achieve deterministic replay for non real-time systems only. Thane [28] extents the approach of LeBlanc towards real-time systems. In his thesis he presents an approach to monitoring, testing and debugging of distributed real time systems. The debugging approach is based on deterministic replay. The program is deterministically replayed offline by observing not only the program specific information, like the communicated messages, but rather all operating system events which could influence the program execution such as interrupts, task switches, and data access. All this events are replayed back by an operating system specific offline version of the real-time kernel, where the real-time clock is disabled and the scheduling is done according to the recorded data.
2.3 The Challenge The steadily rising complexity of distributed hard real-time systems and the need for shorter development times are in conflict. Therefore, in the last years the model-driven development of these systems with high level models and automatic code-generation have been propagated in order to reduce the development costs and time. There are some tools which assist the model driven development of embedded real-time systems like Rational Rose Real-Time2 and Rhapsody3 . Both support both host and target platforms during development but they do not address deterministic replay or the 2 3
http://www-306.ibm.com/software/awdtools/developer/technical/ http://www.ilogix.com/
influence of software-based instrumentation which could lead to false positives or false negatives. Therefore, we can conclude that on the one hand the modelbased approaches fail to exploit the available high level modelbased knowledge in order to support deterministic replay for multiple platforms. On the other hand the traditional approaches (which are not based on models), such as [28], achieve deterministic replay only at the cost of additional hardware and emulators of the target system. Additional hardware, as discussed earlier, is problematic and emulators are also a problem as they often do not support proprietary hardware and there are hardly any guarantees that they really show the same behavior as the target system. Summing up we can conclude that the available solutions for the deterministic replay of distributed hard real-time systems are today taking no advantage of high level information about the system which are present in models and in particular in architectural models. In the remainder of this paper we will outline how we can realize the envisioned platform independent deterministic replay for the specific case of architecture-driven modeling approach of M ECHATRONIC UML and its run-time framework at a much lower cost.
3.
DETERMINISTIC REPLAY
Deterministic Replay for sequential programs without real-time aspects is easy since the same input and same initial state yield the same output independent of operating system effects or other environmental factors such as networking. In the context of distributed real-time systems, the problem is much harder as the independence between the program execution and both the operating system and environmental influences does not hold any more. The observation which motivates our work is the following: deterministic replay in distributed hard real-time systems must be based on recording all relevant events in form of a trace when the original execution happens. Later on when replaying this execution, this trace is used during the execution to ensure that the same inputs (in value and time domain) are fed into the system and that the same outputs are observed. To realize such a replay based on a trace of the original execution, all events which are relevant for the deterministic replay have to be determined. As outlined in the following, it is much more efficient to choose the architectural level to determine the relevant events than the operating system or hardware level. Therefore, we propose in this paper to exploit the high-level abstractions available at the architectural model to achieve the deterministic replay for hard real-time systems with only minimal run-time overhead and without the need for additional hardware. The recording of all events using a classical operating system API and the interference of the process with the operating system must includes things such as the operating system calls, all process switching, operating system scheduling decisions, etc. Such an approach therefore results in a huge amount of data. In addition, replaying this data requires controlling the operating system at a very fine grained level. Both characteristics make any realization of this solution rather complex and costly. If we instead look at the higher-level concept of a component and its interaction with its environment via its port, we can see that a much cleaner and less demanding set of events has to be capture: All in- and outgoing messages as well as their exact timing w.r.t. the component execution. Also instrumenting the system becomes much easier as we do not have to control the scheduling as we can handle the non-determinism at the level of the logical and timed interaction between messages rather than exact scheduling. Doing this step up in the abstraction layers, we also can achieve
platform independence as the API of the run-time framework employs platform independent high-level concepts. Thus, we do not have to adjust the replay to a specific platform. The outlined comparison results in favor of a higher-level solution at the architectural level become even more drastic if we also take into account the networking in case of replaying a distributed scenario. In order to ensure that the operating system subsystem for networking behaves the same, we even have to ensure that all network packets are put in exactly the same buffer location and were delivered with exactly the same timing. Both requirements are usually not realizable for any reasonable, complex third party operating system. In the case of open source operating systems the required modifications might be possible. However, they are extremely costly and it remains at least questionable whether the resulting replayed behavior cannot be altered by the probe effect. In the following we will outline the specific architecture-driven modeling approach in Section 4, the basic run-time framework in Section 5, and finally the required extensions for the platform independent deterministic replay in Section 6.
4. ARCHITECTURE-DRIVEN MODELING To develop an approach which exploits the high level information available at the architectural level in order to provide deterministic replay for distributed hard real-time systems, we chose as underlying architectural-driven modeling approach M ECHATRONIC UML [10, 9]. M ECHATRONIC UML is based on UML 2.0 [23] and focuses on the specification of embedded hard real-time systems for mechatronic systems4 realizing a MDA approach with platform independent and platform specific models (cf. [8]). Its main elements are component diagrams for the modeling of the structure (see Section 4.1) and Real-Time Statecharts for the behavior (see Section 4.2). We will use in the remainder the following example from the railcab research project5 to introduce and explain the employed concepts and to also evaluate our approach. The railcab project proposes to use the passive track system of a classical train system to establish a more flexible and customer-oriented transportation system which is based on intelligent shuttles which operate autonomously and on demand. A wireless communication facility between the shuttles enables their complex coordination in realtime. One major requirement is that the shuttles are able to build convoys to reduce the energy consumption due to air resistance to a competitive level compared to traditional trains. The particular example we employ in this paper is the coordination behavior and the employed decision algorithms which are responsible for building convoys if it is economically appropriate. We further restrict our consideration on the coordination and computation required to establish a convoy and omit the details for breaking them up or failure handling (for more details see [3]). The scheme for building a convoy is roughly the following one: The shuttles know each other from a local section control and thus are able to start negotiations with each other. Whether a convoy is considered useful or not is decided by the first shuttle in the potential convoy (the convoy decider). This convoy decider would later become the convoy coordinator which is responsible for a number of functions as long as the convoy exists, such as distance control. We will in the following restrict our attention to the interaction be4 Mechatronic systems combine traditional mechanical and electrical engineering with software engineering techniques using sophisticated control and coordination techniques (cf. [5]). 5 http://www-nbp.upb.de/en/index.html
tween the shuttles and the convoy decider and omit how the conversation is established beforehand.
4.1 Architecture: Component Diagrams The architecture of the software of the considered hard real-time systems can be specified in M ECHATRONIC UML with UML component diagrams. UML components are self-contained units, where communication via events is restricted to ports. A component can contain other components and events can be delegated from the component to its subcomponents. Ports are the only external access point for components and their provided and required interfaces specifies all interaction which can occur at each port. The interaction between the ports of the components takes place via connectors, which describe the communication channels. shuttle3: Shuttle
shuttle2: Shuttle
shuttle cd 3
shuttle cd 2
shuttle1: Shuttle cd 1
shuttle
decider: ConvoyDecider
Figure 1: Instance view of shuttle and convoy decider Figure 1 depicts a possible instance scenario of our convoy building decision example with three shuttles involved. All shuttles communicate with the ConvoyDecider. Shuttle1 is the convoy leader and therefore has to offer multiple convoy decider ports (cd1, cd2 and cd3) which are internally realized by a contained ConvoyDecider component. The shuttles interact with the convoy decider by the shuttle role while the convoy decider interact with the shuttles via the cd roles.
4.2 Behavior: Real-Time Statecharts The behavior of every component is defined by the periodic execution of the assigned Real-Time Statechart. Real-Time Statecharts extend UML State Machines to be able to model complex realtime behavior. All standard UML State Machines constructs such as hierarchal states, orthogonal states as well as enter-, leave- and, do-methods are supported. Note that the do method is executed periodically. Instead of the when and after construct, the timing can be described using clocks which permit the comfortable specification of complex time constraints even for constraints which span across multiple states using time invariants for states as well as time guards and clock resets for transitions. Beside internal synchronous events in addition asynchronous events are supported. This is realized through queue management that erases events when explicitly consumed. Events are consumed in order of their occurrence and additional transition priorities permit to avoid non-determinism. Synchronous channels are restricted to the local case (between transitions of orthogonal states of the same hierarchical superstate). Sending and receiving of all asynchronous channels can occur simultaneously. For all operations bound to states or transitions we further require Worst Case Execution Times (WCET) attached.
The formal semantics of Real-Time Statecharts is defined by a mapping to Extended Hierarchical Timed Automata (ExHTA) an extension of Hierarchical Timed Automata [14]. /shuttle[i].convoyProposalRejected
NoConvoy shuttle[i].convoyProposal(schedule)
!convoy
Decide enter: convoy=convoyUseful(schedule[])
/shuttle[i].startConvoy {t} /shuttle[i].breakConvoy !convoy /shuttle[i].breakConvoy
Convoy t100 0 simulate based on loaded trace whole environment of component
Figure 13: The configuration file for the run-time framework The excerpt of the configuration file for the run-time framework depicted in Figure 13 shows the possible and required configurations of the framework for the different steps. This is achieved by tracing, synchronization and simulation configuration options.
7.2 Reference Execution The target of the reference execution is a Timesys platform. The three shuttle instances are deployed on three nodes. As seen by the instance view of the application example (cf. Figure 1) an instance
of the convoy decider is part of Shuttle1, as this shuttle is the convoy leader. Therefore, Shuttle1 and ConvoyDecider are deployed on the same node. As described in Section 6.3 during reference execution, we did not log the message body. Omitting the recording of the message bodies leads to significant reduction of the logging amount in our example, because the data for the track schedule which is periodically transmitted needs not to be stored. During reference execution the logging shows that all three shuttles are connected to the convoy decider and the position and the schedule of the tracks should lead to a convoy. Based on this observation the program is re-executed to log all data for diagnosis purpose (cf. Figure 14).
decision. To track down the failure we simulate the whole environment of the convoy decider in combining with a standard gdp debugger to investigate the convoy decider component.
7.3 Simulation The simulation run, which is a deterministic replay of the reference execution, is executed on a Linux platform. The logging of the reference execution is taken as input. As described in Section 6.1 the logged events of the reference execution and the architectural properties are sufficient to guarantee deterministic replay on different platforms. In this step all data to simulate the whole environment of the considered component is recorded to track down the failure by deterministic replay in a standard debugger. To do so, the logging of the reference execution is taken, the interaction is synchronized (cf. Figure 12) to produce the same sequence as by the reference execution and additionally the message body is logged. a) [Message] index=1010 portID=11 sendCount=1 period=34 time_stamp=6063227032 body=16, 1010, 10, 2, 1020, 10, 5, 1030, 20, 15, 1040, 30, 50, 1050, 20, 75 [Message] index=1010 portID=13 sendCount=1 period=35 time_stamp=7013005032 body=10, 1010, 10, 2, 1020, 20, 5, 1230, 10, 19 [Message] index=1010 portID=12 sendCount=1 period=36 time_stamp=7062537032 body=16, 1010, 10, 2, 1020, 10, 5, 1030, 20, 15, 1040, 30, 50, 1050, 20, 75
b) [Message] index=1030 portID=16 sendCount=1 period=36 time_stamp=7102436032
Figure 14: Trace of simulation run Figure 14 a) displays the trace of the logged messages by the convoy decider component and Figure 14 b) shows a cutout of the received brake convoy event. The logged message index is unique for a message type. The portID is the unique port index of the receiving port. SendCount is the number of messages send by the sender port. Period is the period at which the message is computed by the receiver. Time stamp is the receiving time stamp, which is needed to be able to generate the same sequence of events for the Real-Time Statechart. Finally body logs the message body. Case a) has a body and in case b) only the type of the message is needed.
7.4 Diagnosis The observed behavior of the convoy decider example did not meet the expectations. It seems that the convoy decider makes a wrong
Figure 15: Debugging based on platform independent deterministic replay By step-wise execution of the component we find a failure in the convoyUseful method. The track list is ordered by the receiving time of the messages. This index is taken by the convoyUseful method to determine the ordering of the shuttles. As the ordering of the messages is not always the same ordering as the shuttles in the convoy, this assumption can result in a derivation from the expected behavior when the message ordering is not the usual one. Therefore, this defect will only occur in rare cases where the message ordering is disturbed due to network effects. It could not be reproduced when we simply simulate the system with the same input data. Also the effects of the network ordering are properly replayed to reproduce and analyze this defect. Figure 15 shows the execution of the program with a standard debugger.
8. CONCLUSION AND FUTURE WORK In this paper we have presented our approach for the platform independent deterministic replay exploiting the high level information provided by the architectural model of the M ECHATRONIC UML. Based on the formal semantics of the M ECHATRONIC UML and its Real-Time Statecharts, deterministic replay of its components and systems of components are achieved, while only a minimal set of events and data has to be recorded at run-time. In addition, the approach enables deterministic replay on all different hardware platforms for which the run-time framework has been made available. Future work will at first address the formalization of the partial logging of information which shows that the minimization steps do not effect the execution. In addition, a more thorough evaluation of the approach including more detailed studies of the performance trade-offs for different alternative solutions in domains such as railway systems and the automotive domain is planned.
9. REFERENCES [1] M. K. Aguilera, J. C. Mogul, J. L. Wiener, P. Reynolds, and A. Muthitacharoen. Performance debugging for distributed systems of black boxes. In SOSP ’03: Proceedings of the nineteenth ACM symposium on Operating systems principles, pages 74–89, New York, NY, USA, 2003. ACM Press.
[2] G. A. Alvarez and F. Cristian. Simulation-based testing of communication protocols for dependable embedded systems. J. Supercomput., 16(1-2):93–116, 2000. [3] B. Becker, D. Beyer, H. Giese, F. Klein, and D. Schilling. Symbolic Invariant Verification for Systems with Dynamic Structural Adaptation. In Proc. of the 28th International Conference on Software Engineering (ICSE), Shanghai, China. ACM Press, 2006. (accepted). [4] A. Bertolino, F. Corradini, P. Inverardi, and H. Muccini. Deriving test plans from architectural descriptions. In ICSE ’00: Proceedings of the 22nd international conference on Software engineering, pages 220–229, New York, NY, USA, 2000. ACM Press. [5] D. Bradley, D. Seward, D. Dawson, and S. Burge. Mechatronics. Stanley Thornes, 2000. [6] B. Broekman and E. Notenboom. Testing Embedded Software. Addison-Wesley, 2003. [7] S. Burmester, H. Giese, and O. Oberschelp. Hybrid UML Components for the Design of Complex Self-optimizing Mechatronic Systems. In H. Araujo, A. Vieira, J. Braz, B. Encarnacao, and M. Carvalho, editors, Proc. of 1st International Conference on Informatics in Control, Automation and Robotics (ICINCO 2004), Setubal, Portugal, pages 222–229. INSTICC Press, August 2004. [8] S. Burmester, H. Giese, and W. Sch¨afer. Model-Driven Architecture for Hard Real-Time Systems: From Platform Independent Models to Code. In Proc. of the European Conference on Model Driven Architecture - Foundations and Applications (ECMDA-FA’05), N¨urnberg, Germany, Lecture Notes in Computer Science, pages 1–15. Springer Verlag, November 2005. [9] S. Burmester, H. Giese, and M. Tichy. Model-Driven Development of Reconfigurable Mechatronic Systems with Mechatronic UML. In U. Assmann, A. Rensink, and M. Aksit, editors, Model Driven Architecture: Foundations and Applications, volume 3599 of Lecture Notes in Computer Science, pages 47–61. Springer Verlag, August 2005. [10] S. Burmester, M. Tichy, and H. Giese. Modeling Reconfigurable Mechatronic Systems with Mechatronic UML. In U. Aßmann, editor, Proc. of Model Driven Architecture: Foundations and Applications (MDAFA 2004), Link¨oping, Sweden, pages 155–169, June 2004. [11] P. S. Dodd and C. V. Ravishankar. Monitoring and debugging distributed real-time programs. Software - Practice and Experience, 22(10):863–877, 1992. [12] C. Fidge. Fundamentals of distributed system observation. IEEE Softw., 13(6):77–83, 1996. [13] H. Giese. A Formal Calculus for the Compositional Pattern-Based Design of Correct Real-Time Systems. Technical Report tr-ri-03-240, Software Engineering Group, University of Paderborn, Paderborn, Germany, July 2003. [14] H. Giese and S. Burmester. Real-Time Statechart Semantics. Technical Report tr-ri-03-239, Software Engineering Group, University of Paderborn, Paderborn, Germany, June 2003. [15] H. Giese, S. Burmester, W. Sch¨afer, and O. Oberschelp. Modular Design and Verification of Component-Based Mechatronic Systems with Online-Reconfiguration. In Proc. of 12th ACM SIGSOFT Foundations of Software Engineering 2004 (FSE 2004), Newport Beach, USA, pages 179–188. ACM Press, November 2004. [16] H. Giese, M. Tichy, S. Burmester, W. Sch¨afer, and S. Flake.
[17]
[18]
[19]
[20] [21]
[22]
[23]
[24]
[25] [26]
[27]
[28]
[29]
[30]
Towards the Compositional Verification of Real-Time UML Designs. In Proc. of the 9th European software engineering conference held jointly with 11th ACM SIGSOFT international symposium on Foundations of software engineering (ESEC/FSE-11), pages 38–47. ACM Press, September 2003. K. Grimm. Software technology in an automotive company: major challenges. In ICSE ’03: Proceedings of the 25th International Conference on Software Engineering, pages 498–503, Washington, DC, USA, 2003. IEEE Computer Society. H. Kopetz. Real-Time Systems: Design Principles for Distributed Embedded Applications. 395. Kluwer International Series in Engineering and Computer Science, 1997. T. J. LeBlanc and J. M. Mellor-Crummey. Debugging parallel programs with instant replay. IEEE Trans. Comput., 36(4):471–482, 1987. C. E. McDowell and D. P. Helmbold. Debugging concurrent programs. ACM Comput. Surv., 21(4):593–622, 1989. H. Muccini, A. Bertolino, and P. Inverardi. Using software architecture for code testing. IEEE Trans. Softw. Eng., 30(3):160–171, 2004. H. Muccini, M. S. Dias, and D. J. Richardson. Towards software architecture-based regression testing. In WADS ’05: Proceedings of the 2005 workshop on Architecting dependable systems, pages 1–7, New York, NY, USA, 2005. ACM Press. Object Management Group. UML 2.0 Superstructure Specification. OMG Document formal/05-04-01, July 2004. URL: http://www.omg.org/cgi-bin/doc?formal/05-07-04. D. J. Richardson and A. L. Wolf. Software testing at the architectural level. In Joint proceedings of the second international software architecture workshop (ISAW-2) and international workshop on multiple perspectives in software development (Viewpoints ’96) on SIGSOFT ’96 workshops, pages 68–71, New York, NY, USA, 1996. ACM Press. W. Sch¨utz. The Testability of Distributed Real-Time Systems. Kluwer Academic Publishers, Norwell, MA, USA, 1993. W. Sch¨utz. Fundamental issues in testing distributed real-time systems. Kluwer Real-Time Systems journal, 7(2):129–157, 1994. D. Sundmark. Determinstic Replay Debugging of Embedded Real-Time Systems using Standard Components. PhD thesis, Department of Computer Science and Engineering M¨alardalen University, 2004. H. Thane. Monitoring, Testing and Debugging of Distributed Real-Time Systems. Masterthesis, Royal Institure of Technology Stockholm, Sweden, Mechatronic Labor, Department of Machine Design, 2000. J. J. P. Tsai, K.-Y. Fang, H.-Y. Chen, and Y.-D. Bi. A noninterference monitoring and replay mechanism for real-time software testing and debugging. IEEE Trans. Softw. Eng., 16(8):897–916, 1990. F. Zambonelli. An efficient logging algorithm for incremental replay of message. In IPPS ’99/SPDP ’99: Proceedings of the 13th International Symposium on Parallel Processing and the 10th Symposium on Parallel and Distributed Processing, pages 392–398, Washington, DC, USA, 1999. IEEE Computer Society.
