1. Presenter : Shih-Tung Huang Tsung-Cheng Lin Kuan-Fu Kuo 2015/6/15 EICE team Model-Level Debugging of Embedded Real-Time Systems Wolfgang Haberl, Markus Herrmannsdoerfery, Jan Birkez and Uwe Baumgartenx Institut f¨ur Informatik, Technische Universit¨at M¨unchen Garching b. M¨unchen, Germany 2010 10th IEEE International Conference on Computer and Information Technology (CIT 2010)

2. Outline Abstract Introduction to COLA Related work What’s the problem Proposed solution Experiences Conclusion

3. Model-driven development has become the state-of-the- art approach for designing embedded real-time systems. Due to their high level of abstraction, models are easier to understand and verify, thus leading to less faulty systems. But even when combined with automatic code generation, there is still the risk of unintended behavior. This may, for example, arise from real sensor inputs which differ from the characteristics assumed in the model. Consequently, debugging techniques still play an important role, even in model-driven development processes. 3 Abstract (1)

4. However, debugging a system on the embedded target platform is tedious because of the limited user interface. In this paper, we present an approach for capturing runtime data on the target platform and mapping them back to the model. Debugging can then be performed at model-level by visualizing actual input data, like feedback from the target platform’s environment. Using a case study, we demonstrate a realization of our approach. 4 Abstract (2)

5. What is COLA COmponent LAnguage Provide constructs to module a system along different layers of abstraction COLA define three abstraction layers Feature architecture: so-call features Logical architecture: map features onto software architecture Technical architecture: map logical model functionality onto the target platform This paper focus on Logical and Technical architecture layers 5 Introduction

6. Logical architecture Define functional behavior of a system The functional behavior is composed by many states and transitions State is composed by sub-units and channels Sub-unit stand for a task in a state, and channel form orders between tasks 6 Introduction

7. Technical architecture Map system functionality onto the target platform Hardware architecture: the architecture of target platform Cluster architecture: partition the system functionality into distributable entities Allocation: establish the relationship between Hardware and Cluster 7 Introduction

8. COLA was built to tackle the complexity of large scale system in related work[3] After COLA finish model a system, in related work [5] and [6], it can automatic generate executable distributed code which can be executed on platform When code be executed on platform, in related work [7], all software components communicate around through the middleware It mean middleware can record the exchange data between software components in related work [8], it can simulate the system operation when we give environment condition argument 8 Related work

9. Even in such generated system may product failures Due to faults contained in the system specification limited knowledge about the exact environmental conditions Traditional debug method can not find out the problem of above Only find out functionality bugs 9 What’s the problem

10. For simulation can be realized, this paper propose a method below First, they modify code generation (related work [5] and [6]) for indicating state number Second, use the middleware (related work [8]) on platform for tracing data on running time Third, do the data extraction, then feedback the information to each module for realizing simulation 10 Proposed solution

11. Code generation generate executable distributed code which can be executed on platform produce configure file for middleware When system startup the middleware can read the cluster and their ports information which want to be traced Captured data of ports can map back to the model by their unique middleware address 11 Code generation (1) State number Nested State Top is a automaton state

12. Problem: the state number is difficult map back to the model Due to state number is formed by chunk data solution: use the additional annotation to connect the relationship between every level’s automaton 12 Code generation (2)

13. middleware can trace the data transfer and state change When every cluster want to communication with others, the request must be translated into read or write call to middleware Every cluster use middleware to load or store their state number This paper focus two issue for tracing data First, the trace storage format should be compact as possible as we can Second, no complicated transformations to save processing resource 13 System execution

14. Due to the reason of above, the storage format is simply Binary format Just only two definition in header TASK: specifies the types used for the state values DATA: what ports’ data of cluster want to be recorded when data extraction the specific properties such as endianness and sizes of primitive data types must be noticed 14 Data extraction

15. This paper use a parking system based on several distance sensors to prove the viability of above approach There have three ECUs Input (sensors): 2 infrared, 1 supersonic sensors and Bluetooth Output (actuator) : motor and steering, indicator, reversing, and breaking lights Middleware: top of the network for data exchange and clock synchronization services parking cluster contained 115 units and was traced for 147 invocations, corresponding to 14.7 seconds The generated trace file was 45 KByte in size 15 Experiences

16. At first, this paper describe the problem they want to solve and their contribution clearly Second, they introduction the COLA and through now what it become Related work [4]~[7] Third, propose what method do they use to solve the problem Final, they use experiences to show why then want to solve this problem and testing result 16 Conclusion