To deal with increasing size and complexity, component-based software development has been employed in embedded systems. Due to several faults, components can make wrong assumptions about the working mode of the system and the working modes of the other components. To detect mode inconsistencies at runtime, we propose a "lightweight" error detection mechanism, which can be integrated with component-based embedded systems. We define links among three levels of abstractions: the runtime behavior of components, the working mode specifications of components and the specification of the working modes of the system. This allows us to detect the user observable runtime errors. The effectiveness of the approach is demonstrated by implementing a software monitor integrated into a TV system. © 2012 Springer-Verlag London Limited

Akşit, M.

Hofmann, C.

Sözer H.

Tekinerdoǧan, B.

Bilkent University Institutional Repository

Runtime Verification of Component-BasedEmbedded SoftwareHasan Sözer, Christian Hofmann, Bedir Tekinerdoğanand Mehmet AksitAbstract To deal with increasing size and complexity, component-based softwaredevelopment has been employed in embedded systems. Due to several faults,components can make wrong assumptions about the working mode of the systemand the working modes of the other components. To detect mode inconsistencies atruntime, we propose a ‘‘lightweight’’ error detection mechanism, which can beintegrated with component-based embedded systems. We define links among threelevels of abstractions: the runtime behavior of components, the working modespecifications of components and the specification of the working modes of thesystem. This allows us to detect the user observable runtime errors. The effec-tiveness of the approach is demonstrated by implementing a software monitorintegrated into a TV system.1 IntroductionAn evident problem in the embedded systems (ES) domain is the increasingsoftware size and complexity. As a solution, component-based development hasbeen recognized as a feasible approach to improve reuse and to ease the creation ofThis work has been carried out as part of the TRADER project under the responsibility of theEmbedded Systems Institute. This project is partially supported by the Netherlands Ministry ofEconomic Affairs under the Bsik program.H. Sözer (&)Özyeğin University, Istanbul, Turkeye-mail: hasan.sozer@ozyegin.edu.trC. Hofmann  M. AksitUniversity of Twente, Enschede, The NetherlandsB. TekinerdoğanBilkent University, Ankara, TurkeyE. Gelenbe et al. (eds.), Computer and Information Sciences II,DOI: 10.1007/978-1-4471-2155-8_60,  Springer-Verlag London Limited 2012471variants of products [1]. Hereby, usually each component has to deliver a set ofwell defined services in a set of working modes. Components can correctlywork together in the integrated system only if their working modes are con-sistent with each other; however, several faults can lead to mode inconsisten-cies at runtime.We observed that mode inconsistencies between components can cause severeerrors that lead to user-perceived failures. To detect and recover such errors,dedicated fault tolerance mechanisms are required. Instead of tolerating faults, onemay try to avoid them by adopting theorem proving and model checking tech-niques at design time. Although these techniques have showed their value formany practical applications, the existing tools do not scale-up easily. Moreover,some faults may simply remain undetected during design and/or new faults may beintroduced during the implementation.In our approach, we define 3 levels of abstractions: the runtime behavior of thecomponents, the working mode specifications of components and the specificationof the working modes of the system. We establish explicit links among theselevels. This allows us to detect runtime errors caused by inconsistent workingmodes of components. The effectiveness of the approach is demonstrated with asoftware monitor integrated into a TV system.The remainder of this paper is organized as follows. Section 2 introduces theproblem using an industrial case. Our solution approach is described in Sect. 3.Section 4 proposes diagnosis and recovery techniques. Section 5 discusses theeffectiveness and the limitations of the solution approach. In Sect. 6, relatedprevious studies are summarized. Finally, the paper is concluded in Sect. 7.2 Industrial CaseIn this section, we illustrate the problem using digital TV (DTV) as an industrialcase. The DTV software is composed of many components working in coordi-nation [1]. Each component has a set of working modes. These modes should bemutually consistent to provide the functionality that is required by a working modeof the system. If the synchronization between the component’s working modes islost (by loosing a notification message, data corruption etc.) inconsistent behavioroccurs and component interactions no longer work in the anticipated way.Consider for example the Teletext Page Handler component, which isresponsible for requesting and acquiring a teletext page. Another component,Display Manager renders teletext pages on the screen. If Display Manager cor-rectly assumes that the TV is in Teletext mode whereas Teletext Page Handlerassumes that the TV should display the video stream, the combined behavior leadsto a failure: no Teletext page is rendered leaving the user with a blank screen.Due to the large number of components and the cost sensitivity of the ESdomain, it is not feasible to check mode consistencies at the system level.Therefore, we propose to detect mode inconsistencies at component level asfollows.472 H. Sözer et al.3 Error DetectionOur approach is based on models of the working modes of the system and itscomponents. We map the models describing the component working modes to theimplementation of the corresponding component in order to observe the compo-nent modes at runtime. We also map all component modes to the system modes.This makes the inter-dependencies between component modes explicit. Themappings between modes specify the mutual consistency condition, which ischecked by monitoring the system at runtime. An error is detected whenever aninconsistency has been observed. In the following, we will discuss a prototypeimplementation of this approach in more detail. Then, we generalize this imple-mentation and provide a formal definition of the mode consistency condition.3.1 Implementation: A PrototypeThe number of errors that can be detected by our approach depends on the numberof working modes of the system that is considered and the number of componentmodes that are monitored. We developed a prototype and integrated it into a realTV system, where 4 system working modes are considered and 3 components aremonitored. System working modes are TV, Txt, dual screen, and transparentteletext. The monitored components are Teletext Page Handler, Display Manager,and Application Manager. The Application Manager component controls theexecution of applications in the system. Each component mode is represented by abit vector, hb0b1b2b3i; where each bit corresponds to a system working mode, e.g.,b2 corresponds to dual screen. The mapping between the system working modesand the component modes is shown in Table 1.Application Manager, Teletext Page Handler and Display Manager compo-nents can be in one of 4, 3 and 4 different modes, respectively. In total, there are3 4 4 ¼ 48 different mode combinations. AND ing the bit vector representa-tions of the component modes leads to the value 0 in 40 of the cases. In 8 cases theresult is non-zero, i.e., there is at least one bit where all of the component modeshave the value 1. Therefore, our prototype can detect 40 error cases. The errordetection mechanism polls the system periodically, where the current state valuesof the components are ANDed and an error is issued if the result is 0.Table 1 Mapping between the component modes and the 4 system working modesApplication manager Txt page handler Display managerMode Map Mode Map Mode MapOn screen display 1000 On 111 On screen display 1000Txt 0111 Off 1000 Txt full screen 0100Off 0000 subtitle 0111 Txt left-half screen 0010TV 1000 Default screen 1000Runtime Verification of Component-Based Embedded Software 473We injected 4 different faults in the TV system. These lead to mode incon-sistencies between the Teletext Page Handler and Display Manager components,which eventually end up in lock-up failures in the Teletext functionality. Wesystematically activated the faults with a key combination from the remote control.In all cases the detection mechanism was able to detect the errors (notified byblinking the TV status LED) even before we observed the associated failure. Thisallows to (possibly) recover from an error before a failure is perceived by the user.3.2 Generalization of the PrototypeIn this section, we generalize and formalize our approach. We define a finite set ofcomponents C, where for each component Ci 2 C; there exists a set of workingmodes Mi: Furthermore, there exists a set of working modes of the system MS: Foreach mode couple (m,s) s.t. m 2 Mi and s 2 MS; we define a mapping function,mapðm; sÞ ¼ 0; s) Að:mW:sÞ1; otherwisewhere s) Að:mW:sÞ is a Computational Tree Logic [2] formula denoting thatwhen s occurs, m should never occur until the mode of the system changes. Forevery mode m 2 Mi of a component Ci; we define a bit-vector vi;m of length MSj j:Each bit in vi;m refers to a mode s in MS and its value is assigned according to themapping function. The consistency condition is defined asV0 i\ Cj j vi;m; wherevi;m corresponds to the current mode of component Ci: There exists an error if thiscondition is evaluated to 0, meaning that there is no consistent assumption of eachcomponent about the current mode of the system.3.3 Performance OverheadTo measure the performance overhead introduced by the error detection mecha-nism, we used an existing feature of the system that measures the load in terms ofCPU cycles. We have made load measurements during two scenarios; watchingTV (TV) and reading a Teletext page (TXT). For each scenario, we calculated themaximum, minimum and average CPU load of the system with and without theerror detection mechanism. The results are presented in Table 2.In Table 2, we see that the CPU load during the TV scenario did not differ at all.For the TXT scenario, the average CPU loads was increased by 1,2% on average.This shows that the overhead introduced by the error detection mechanism canvary depending on the usage scenario. In the case of the TV and TXT scenarios, theoverhead is at acceptable levels. In general, our approach provides severaladvantages in terms of simplicity and efficiency. Error checking is performed witha single AND operation over bit-vectors and a space of size ð Cj j  SGj jÞ bits must474 H. Sözer et al.be allocated only. Also note that the modeling effort is limited to assigning binaryvalues that indicate the mode compatibility.4 Diagnosis and RecoveryError detection is the main focus in this paper. Another essential step of faulttolerance is recovering from the detected errors. We have recently developed alocal recovery framework [3] for this purpose. Local recovery is an effectiveapproach, in which the recovery procedure takes actions concerning only theerroneous components. To make local recovery possible, an additional diagnosisstep should be introduced, which identifies the components that do not have aconsensus on the current system mode. We can apply a voting mechanism topinpoint such components in Oð SGj j  Cj jÞ time as shown in Algorithm 4.Algorithm 1 Diagnosis Procedure1. systemmode ø2. maximumvotesum 03. for j ¼ 0! SGj j do4. votesum 05. for i ¼ 0! jCj do6. votesum votesum þ vi;mcurrent ½j7. end for8. if maximumvotesum\votesum then9. systemmode j10. maximumvotesum votesum11. end if12. end for13. for i ¼ 0! jCj do14. if vi;mcurrent ½systemmode 6¼ 1 then15. mark the component Ci16. end if17. end forTable 2 CPU load of the system with and without error detectionScenario Without error detection With error detectionMin.(%) Avg.(%) Max.(%) Min.(%) Avg.(%) Max.(%)TV 34 36.9 51 34 36.9 51TXT 39 42.9 46 41 43.4 47Runtime Verification of Component-Based Embedded Software 4755 DiscussionWe assigned the monitor to the lowest priority task, which can proceed after allthe other tasks become idle. This provides a safe point in time to perform theerror checking: (i) the monitor does not intervene with other tasks and func-tions, (ii) the system reaches to a stable state before the mode information iscollected, and (iii) the introduced performance degradation is negligible. Theonly drawback of this approach is that error detection might be late. Errorchecking may never have a chance to execute in case the system is continu-ously busy or deadlocked. Such errors can be detected by other mechanismslike watchdog [4].6 Related WorkThere have been several proposals regarding formal specification of behavior[5–7]. Behavior protocols [8] and contracts [9] have been mainly used to formalizecomponent interaction and utilized for design-time verification.The scheme proposed by Thai et al. in [10] detects errors by checkingconsistency of states. The decision about whether there exists an error or not ismade statistically. The outcome is according to the ratio between checks thatpassed and the total number of checks executed. Our approach is deterministic inthe sense that an error is issued whenever a check does not pass.Classification schemes have been provided for on-line monitoring [11] and real-time system monitoring [12]. We can classify our work as a monitoring approachfor fault tolerance. It is based on time-driven sampling of component modes andbuilt-in event interpretation that triggers recovery actions.7 ConclusionWe pointed out a problem associated with component-based software that con-stitutes a challenge for reliability of ES. Either because of implicit assumptions atthe design level or faults introduced during the implementation, mode inconsis-tencies can occur between components, which end up with the failure of thesystem. Such errors can be detected and recovered, (possibly) before a failure isobserved. In this paper, we proposed an error detection mechanism that can detectmode inconsistencies at runtime. It can be adopted independent of the utilizedcomponent technology. We implemented a prototype of our solution and inte-grated it into a TV system. We obtained promising results.476 H. Sözer et al.References1. van Ommering, R.C., et al.: The Koala component model for consumer electronics software.IEEE Comput. 33(3), 78–85 (2000)2. Emerson, E.A., Clarke, E.M.: Using branching time temporal logic to synthesizesynchronization skeletons. Sci. Comput. Program. 2(3), 241–266 (1982)3. Sozer, H., Tekinerdogan, B., Aksit, M.: FLORA: a framework for decomposing softwarearchitecture to introduce local recovery. Softw. Pract. Exper. 39(10), 869–889 (2009)4. Huang, Y., Kintala, C.: Software fault tolerance in the application layer. In: Lyu, M.R. (ed.)Software Fault Tolerance, pp.231–248. John Wiley & Sons, Chichester (1995)5. Peters, D.K., Parnas, D.L.: Requirements-based monitors for real-time systems. IEEE Trans.Softw. Eng. 28(2), 146–158 (2002)6. Zulkernine, M., Seviora, R.: Towards automatic monitoring of component-based softwaresystems. JSS ACBSE Special Issue 74(1), 15–24 (2005)7. Diaz, M., Juanole, G., Courtiat, J.: Observer—a concept for formal on-line validation ofdistributed systems. IEEE Trans. Softw. Eng. 20(12), 900–913 (1994)8. Plasil, F., Visnovsky, S.: Behavior protocols for software components. IEEE Trans. Softw.Eng. 28(11), 1056–1076 (2002)9. Berbers, Y. et al.: CoConES: an approach for components and contracts in embeddedsystems. LNCS 3778, 209–231 (2005)10. Thai, J., et al.: Detection of errors using aspect-oriented state consistency checks. In: ISSRE,pp. 29–30 (2001)11. Schroeder B.: On-line monitoring: a tutorial. IEEE Comput. 46(25), 72–78 (1995)12. Schmid, U.: Monitoring distributed real-time systems. Real-Time Syst. 7(1), 33–56 (1994)Runtime Verification of Component-Based Embedded Software 477

Runtime verification of component-based embedded software

http://repository.bilkent.edu.tr/bitstream/11693/28128/1/Runtime%20verification%20of%20component-based%20embedded%20software.pdf

Runtime verification of component-based embedded software

Abstract

Similar works

Full text

Available Versions

Bilkent University Institutional Repository