On-board Fault Detection, Isolation and Recovery (FDIR) systems are considered to ensure the safety and to increase the autonomy of spacecrafts. They shall be carefully designed and validated. Theirimplementation involves a relevant knowledge of items like functions and architectures of the system, and a fault model in relation with these items. Thus, the event-B method is well suited to correctly specify and validate on-board safety architectures. This paper focuses on the FDIR concept presentation and the use of event-B for formalising and for refining the FDIR concept

Dadeau, Frédéric

Lamboley, Julien

Moutet, Thierry

Potet, Marie-Laure

English

Crossref

Abstract State Machines, B and Z

Chaudemar, Jean-Charles

Castel, Charles

Seguin, Christel

Open Archive Toulouse Archive Ouverte

FDIR Architectures for Autonomous Spacecraft:Specification and Assessment with Event-BJean-Charles Chaudemar1, Charles Castel2, and Christel Seguin21 ISAE-DMIA, Toulouse, France2 ONERA-DCSD, Toulouse, FranceAbstract. On-board Fault Detection, Isolation and Recovery (FDIR)systems are considered to ensure the safety and to increase the auton-omy of spacecrafts. They shall be carefully designed and validated. Theirimplementation involves a relevant knowledge of items like functions andarchitectures of the system, and a fault model in relation with theseitems. Thus, the event-B method is well suited to correctly specify andvalidate on-board safety architectures.This paper focuses on the FDIR concept presentation and the use ofevent-B for formalising and for refining the FDIR concept.1 IntroductionOn-board Fault Detection, Isolation and Recovery (FDIR) systems aim at main-taining the safe spacecraft operation even when faults occur. They also enable tolimit service interruptions with reduced ground operations. So, they contributeto the spacecraft autonomy.They are complex systems composed of various mechanisms, ranging from themonitoring and activation of basic physical devices to the reconfiguration of thespacecraft mission. They are often structured in layers to master this complexity.One issue is to characterize and validate each layer and the relationship betweeneach layer.These characteristics require a rigorous and progressive validation of thesystem from the early phases of design by discharging proof obligations. Accord-ingly, it is necessary to use a formal method like event-B for the modelling andproof.This paper focuses on the FDIR concept presentation and the use of event-Bfor formalising and for refining the FDIR concept.The paper is organised as follows: after a short presentation of on-boardFDIR concept strongly bounded with autonomy architecture concept, the nextsection suggest activities enabling to implement FDIR concept. Then, we presentthe framework of formal modelling that we will use to describe our architectureand the properties related to this architecture. The last section deals with theobjectives for the future work.22 FDIR conceptFDIR is the means to detect off-nominal conditions, isolate the problem to aspecific subsystem/component, and recover of vehicle systems and capabilities[1]. In this paper, FDIR is considered as an operational function that contributesto the autonomy of the system and whose main purpose is to maintain the avail-ability and the safety of the system [2].The main activities related to FDIR design concern:– identification of fault-classes that could impact the requested availability andsafety objectives;– proposition of a strategy in order to tolerate above fault-classes. A strategysuggests a logical solution to achieve these objectives;– implementation of this strategy by proposing a static and dynamic architec-ture: combining functional components with safety components for diagnosisand reconfiguration.One difficulty is often the lack of traceability between these activities. The strat-egy that gave the rationales of the architecture is left implicit. The proposedarchitecture is often the result of expert judgement. So it is hard to prove theconsistency between the objectives and the architecture. Therefore our proposi-tion is to model the objectives of the concerned system using event-B method. Wefirst model some strategies or patterns of safety that allow to meet requirementsdescribed in the objectives of the system. Then, we show how these patterns arerefined rigorously in concrete architectures by discharging proof obligations.3 Work in progress using event-B methodEvent-B is a formal method for the development of complex system. Its formal-ism supports the validation of some properties thanks to proof methods. Thanksto these distinctive features, the event-B method is well suited to correctly spec-ify and progressively validate on-board safety architectures.Let us illustrate how the three activities are modelled in event-B. For mis-sion objectives of a spacecraft, two feared events are identified: the spacecraftloss and the interruption the mission. Safety architecture patterns propose microarchitecture solutions that enable to mitigate such feared events. We propose toreuse and extend the patterns presented in [3].For this paper, we model more specifically a safety architecture pattern thatincludes a primary functional component and a redundant one, under the hy-pothesis of no common fault. The safety property to be met is: “one single faultshall not lead to the total loss of the function”. We modelled this pattern atthree abstraction levels successively refined which verify this property.3The most abstract model enables to formalise this property and hypothesis.Two basic components are considered. A fault counter (fault ci, with i standsfor 1 or 2) is associated to each component, whereas a boolean status (status)models the global system health. When a fault occurs (event disci, with i standsfor 1 or 2), the component “i” is considered disconnected. When the event fi-nal occurs, nothing more happens, since the system remains in the faulty state.Moreover, for all this behaviour, the safety property is expressed by an invariant:card(fault c1) + card(fault c2) ≤ 1⇔ status = TRUE. But at this step, thereis no detail about the condition of spare component activation.Accordingly, the second model refines the former with introduction of theswitching process as a strategy. The activation variables are set in this newmodel. Two new events are defined: sw1 2 event allows to switch from the pri-mary active component to the spare component which becomes active when theprimary one is disengaged; sw2 event disconnects the system by disconnectingthe secondary component.At least, the third model is an implementation of this switching strategy bytaking into account data flow: normal1 (respectively normal2) event representsthe “normal” data flow of the primary (respectively, the spare) component ac-cording to the specification; fail1 (respectively fail2) event represents the “faulty”data flow of the primary (respectively, the spare) component.4 Future workThe current work investigates B-event specifications and refinements of genericFDIR strategies by using the RODIN platform. The future work will consistin studying the impact of the concept of a “layered” FDIR and how it can bemodelled and validated in the B-event framework, in the same spirit than thefull constructive approach developed by [4].References1. NASA: Glossary - NASA Crew Exploration Vehicle, SOL NNT05AA01J, Attach-ment J-6. http://www.spaceref.com/news/viewsr.html?pid=15201 (2005)2. Chaudemar, J.C., Castel, C., Gabard, J.F., Tessier, C.: Z and ProCoSA basedspecification of a distributed FDIR in a satellite formation. In: CAR’07 - SecondNational Workshop on Control Architectures of Robots, Paris, FR (2007)3. Kehren, C.: Motifs formels d’architectures de syste`mes pour la suˆrete´ de fonction-nement. SUPAERO, Toulouse, FR. (2005)4. Arora, A., Kulkarni, S.: Component based design of multitolerant systems. SoftwareEngineering, IEEE Transactions on 24(1) (1998) 63–78

Component based design of multitolerant systems.

Motifs formels d’architectures de syst` emes pour la sˆ uret´ ed ef o n c t i o n -nement. SUPAERO,

NASA Crew Exploration Vehicle,

Z and ProCoSA based speciﬁcation of a distributed FDIR in a satellite formation. In:

FDIR architectures for autonomous spacecraft: specification and assessment with event-B

International audienceWe propose a formal framework based on the B method, that supports the development of secured smart card applications. Accordingly to the Common Criteria methodology, we start from a formal definition and modelling of security policies, as access control policies. At the end of the development process, smart card applications are implemented in a standardized way, based on both the life cycle of smart card applets and the APDU protocol. In this paper, we define a conformance relationship that aims at establishing how smart card applications can be related to security requirement models. This embraces both the notions of security conformance as well as traceability allowing to relate basic events appearing at the level of applications with abstract security policies. This approach has been developed in the RNTL POS´E project1, involving a smart card issuer, Gemalto

Hal - Université Grenoble Alpes

A Verifiable Conformance Relationship between Smart Card Applets and B security Models

BORGER, EGON

THALHEIM B.

Archivio della Ricerca - Università di Pisa

Modeling Workflows, Interaction Patterns, Web Services and
Business Processes: The ASM-Based Approach

International audienceWe present in this paper a way to produce test suites for the POSIX mini-challenge, based on a formal model of a file system manager, written using a B machine. By this case study, we illustrate the limitations of a fully-automated testing process, which justifies the use of scenarios that complements the classical functional testing approach. Scenarios are expressed through schemas, focusing only on operation chaining. They are played on the model using a symbolic animation engine in order to automatically compute pertinent operation parameter values, based on model coverage criteria such as behavioral or data coverage. We concretize our experimentation by testing the POSIX conformance of two different file systems: a recent Linux distribution, and a customized Java implementation of POSIX used to evaluate the relevance of our approach

FDIR architectures for autonomous spacecraft: specification and assessment with event-B

Abstract

Similar works

Full text

Available Versions