CS448/548 Sequence 23Design Methodology for Survivable Systems!How does your systems execute?–Is everything normal?–Is something out of the ordinary?!Let us consider dynamic monitoring of an executing system–Formalism of discussion based on: –John Munson, Axel Krings and Robert Hiromoto, "The Architecture of a Reliable Software Monitoring System for Embedded Software Systems", ANS 2006 Winter Meeting and Nuclear Technology Expo!Recall reading assignment 10 in sequence 161CS448/548 Sequence 23Discussion of application!IntelliDrive–Vehicle-to-Vehicle–Vehicle-to-Infrastructure–Safety concerns–Availability concerns–Survivability concerns2CS448/548 Sequence 23A system in execution!Embedded mission critical systems–Dynamic run-time monitoring–Requirements»must continue operating in the face of departure from nominal operation scenarios»formalize nominal system activity»detect departure from nominal operating scenarios in timely fashion»reconfigure essential operations by remapping onto components still operational3CS448/548 Sequence 23System Profile!What is a certified profile?!What is an uncertified profile?!What is the difference between an uncertified profile and anomalous behavior?!Scenarios–a system component fails–the software component fails–the system behaves in a way that was not observed before–malicious attack has occurred–user initiates sequence of uncertified operations4CS448/548 Sequence 23Contingency management!First step in designing survivable high-confidence system:–Creation of contingency management system to detect the anomalous activity of an executing system –Resolution of problem at the lowest level of program module granularity5CS448/548 Sequence 23General Design Overview!Choices–Software allowed to continue operation by eliminating functionality that led to failure event–Software may duplicate mission critical functionalities by associative remapping of available functionalities!What is needed though? –Fault detection?–Fault masking?–How do you know what happened?6CS448/548 Sequence 23Real-time monitoring!Software must be designed to work in conjunction with real-time monitoring system7input is detected (data types, variable range, etc.) or achoice of non-standard combination of operations isselected. This is the principal reason that a program mayhave demonstrated great reliability in past performancesbut may suddenly become quite unreliable when requiredto adapt to changes in the manner in which the userinteracts with the system. In other words, the pastperformance of a software system, from the standpoint ofreliability, is not at all a good predictor of the futurereliability of the system. Our previous investigations intothe etiology of software failures in the Primary AvionicsSoftware System of the Space Shuttle have providedsubstantial insight into this view of software reliability.On the basis of that work, it is now clear to us that it is notthe software system that fails but rather the softwaresystem executing a particular operation that fails.III. MODEL DESCRIPTIONOne of the single most important aspects of thesystem's reliability is its behavior at run-time, i.e., its run-time profile.III.A Certified ProfilePerhaps the greatest threat to the reliableoperation of a modern embedded software system is theunanticipated operational demands placed on the systemby the operational environment. As a consequence thesystem may well shift from a reliable (certified by thesoftware developer) operational profile to an uncertifiedprofile. In the event that a system is driven to operateunder an uncertified operational profile, it will beimportant to understand whether the new behavior can betested and possibly certified as reliable. This assumes, ofcourse, that the software system is suitably instrumentedto provide sufficient information to reconstruct the systemactivity and validate the correctness of that behavior andthe associated system components. The main objective ofthe dynamic measurement methodology from thestandpoint of high-confidence software systems is to trap,in real-time, any behavior that is considered uncertified.We hypothesize that it is possible from the observedbehavior of the software modules to determine with acertain level of confidence the future reliability of asystem under one or more certified operational profiles.III.B Uncertified ProfileWe subscribe to the notion that uncertifiedbehavior constitutes anomalous behavior that hasimportant consequences. The detection of an anomalousbehavior is a likely indication that the software/hardwarecomponent has failed, a malicious attack has occurred, orthat the users has initiated a sequence of uncertifiedoperations [3]. The failure event itself is made tangiblethrough such an anomalous process. The first step, then,in the design of a high-confidence system is the creationof a contingency management system to detect theanomalous activity of an executing system and resolve theproblem at the lowest level of program modulegranularity.III.C. General Design OverviewGiven that a failure has occurred there are twopossible avenues that the design process may take toinsure that the software system will continue to operateafter the failure event. First, the software system may beallowed to continue operating by eliminating thefunctionality that led to the failure event. Alternatively,the software may be designed to duplicate vital or missioncritical functionalities by an associative remapping ofavailable functionalities; in which case, the failure of acritical functionality can be recovered once detected.Dependability considerations are based on the conceptthat, to insure a high level of reliability in an executingsoftware system, a program must be designed to work inconjunction with a real-time monitoring system. Theprinciple considerations are two-fold. On the one hand,one has to monitor the activity of an executing programfor the distribution of activity across program modulesand also for potential failure events at the module level.The second consideration is to control the structure of theexecuting program. To perform this function, one needsto provide a new loaded program with an initial callstructure that will control the execution sequence ofprogram modules in the executing program. Furthermore,one may have to alter the structure of the executingprogram in the event that a failure has been detected at theprogram module level.The