assured reconfiguration: an architectural core for system
TRANSCRIPT
UVA Dependability Research Group
Assured Reconfiguration:An Architectural Core
For System Dependability
ICSE 2005Workshop on Architecting Dependable Systems
John KnightUniversity of Virginia
Joint work with Elisabeth Strunk
Assured Reconfiguration 2May 2005
UVA Dependability Research Group
The Challenge
Hardw
areC
osts
Desired Functionality
SystemHardwareVolume
SystemSoftwareVolume
Com
plex
ity
Safety-CriticalApplications
Assured Reconfiguration 3May 2005
UVA Dependability Research Group
Implications Of The ChallengeSystem:
Distributed processing/Integrated Modular AvionicsHigh data communications demand
Hardware:Replication to meet MTBF demands
Software:Increased volume, complexity, functionality
And it is bound to continue for the foreseeable future…
Assured Reconfiguration 4May 2005
UVA Dependability Research Group
Meeting The Challenge?All defects can have serious consequences in typical systems but…Hardware replication:
Expensive, bulkyIncreased weight, power, space, shielding
Software complexity:Mostly outside the realm of assurance techniques
Trying to deal with this by restricting amount of function in systems is naïveCan we continue with “business as usual”?
Assured Reconfiguration 5May 2005
UVA Dependability Research Group
Business As Usual For Hardware?
Degradation
Faults
Des
ign
Faul
ts
MTB
F
Hardware Is MuchMore Reliable Than It
Used To Be
R E P L I C A T I O NTime
Business as usual unnecessary
Assured Reconfiguration 6May 2005
UVA Dependability Research Group
Business As Usual For Software?Why is software so difficult?
Fluid mechanics:Continuous mathematicsNavier-Stokes equation
Structural analysis:Continuous mathematicsFinite element method
Software:Discrete mathematics?
Business as usual unlikely to succeed
DevelopmentBased OnAnalysis
Assured Reconfiguration 7May 2005
UVA Dependability Research Group
ClaimMaintaining Complete
Functionality With Ultra High
Assurance Is Unnecessary
OccasionalOperation With
Reduced But Safe Functionality Is
Satisfactory
Basing System Design On These AssumptionsReduces Complexity And Cost
ASSURED RECONFIGURATION
Hardware Degradation Faults
Are Much Less Frequent Than In
The Past
Assured Reconfiguration 8May 2005
UVA Dependability Research Group
What Is Assured Reconfiguration?
Explicit decision at specification level to define a tradeoff between system dependability and functionExplicit decision by system stakeholders to accept alternative functionality if errors do occurBecause:
Complete hardware masking is too expensiveAdequate software fault avoidance/removal is infeasible
CommonCases
Assured Reconfiguration 9May 2005
UVA Dependability Research Group
What Is Assured Reconfiguration?
Faults Faults
Reliability, Availability Assured Reconfiguration
x
$f()
f() f()f()
g()h()
j()
Target Configuration Depends On Conditions
Assured Reconfiguration 10May 2005
UVA Dependability Research Group
Aircraft flight control softwareFAA software development standard:
Minor:Anticipated to occur one or more times during the entire operational life of each airplane
Major:Not anticipated to occur during the entire operational life of asingle random airplane
Catastrophic:Not anticipated to occur during the entire operational life of all airplanes of one typeFailure rate of 10-9 per hour of operation
Example: Modern Avionics Systems
Assured Reconfiguration 11May 2005
UVA Dependability Research Group
Example: Modern Avionics Systems
These requirements:Cannot be assured with current approachesAre essentially impossible to demonstrate
But, some (most?) functionality:Does not need to be reliableNeeds to be fail-stop with ultra high dependability
Assured reconfiguration is an option to achieve system goals
Assured Reconfiguration 12May 2005
UVA Dependability Research Group
Prior Work on ReconfigurationSurvivability in critical information systems
Different requirements for embedded systemsAlternative functionalities (Shelton and Koopman)
Provides a model of system utilityGraceful degradation
Maximum utility with working components
Assured Reconfiguration 13May 2005
UVA Dependability Research Group
Prior Work on ReconfigurationQuality of service
Specific aspects of a systemSimplex architecture (Sha)
Assumes analytic redundancyCurrent systems, e.g., Boeing 777
Ad-hocAre built using facilities already provided by the system
Assured Reconfiguration 14May 2005
UVA Dependability Research Group
Assured System Reconfiguration
VisionReconfiguration As Architectural Foundation
Fail-StopComputer
Fail-StopSoftware
Component
Fail-StopComputer
Fail-StopComputer
Fail-StopSoftware
Component
Fail-StopSoftware
Component
Fail-StopSoftware
Component
Fail-StopComputer
Assurance By Proof
Assured Reconfiguration 15May 2005
UVA Dependability Research Group
Proposed ApproachSystem architecture:
Fully distributed, arbitrary layout and number of partsUltra-dependable data bus, e.g., TTP
Computing and storage hardware:Allow computers to fail, butUse ultra-dependable fail-stop machines
Software:Allow application software to fail, butUse ultra-dependable, fail-stop applications
Ultra-dependable reconfiguration mechanism
Assured Reconfiguration 16May 2005
UVA Dependability Research Group
OperatingSystemGeneralPurpose
Computer
AvionicsApplication
Proposed Approach
OperatingSystemGeneralPurpose
Computer
OperatingSystemGeneralPurpose
Computer
AvionicsApplication
AvionicsApplication
High Speed Data Bus
OperatingSystemGeneralPurpose
Computer
AvionicsApplication
High Speed Data Bus
Common Components
ComponentsAdded As Needed
Assured Reconfiguration 17May 2005
UVA Dependability Research Group
OperatingSystemGeneralPurpose
Computer
AvionicsApplication
Proposed Approach
OperatingSystemGeneralPurpose
Computer
OperatingSystemGeneralPurpose
Computer
AvionicsApplication
AvionicsApplication
High Speed Data Bus
Fail StopGeneral Purpose
ComputerOperatingSystemGeneralPurpose
Computer
AvionicsApplication
High Speed Data Bus
Assured Reconfiguration 18May 2005
UVA Dependability Research Group
OperatingSystemGeneralPurpose
Computer
AvionicsApplication
Proposed Approach
OperatingSystemGeneralPurpose
Computer
OperatingSystemGeneralPurpose
Computer
AvionicsApplication
AvionicsApplication
High Speed Data Bus
OperatingSystemGeneralPurpose
Computer
AvionicsApplication
Ultra Dependable, ReconfigurableHigh Speed Data Bus
Assured Reconfiguration 19May 2005
UVA Dependability Research Group
OperatingSystemGeneralPurpose
Computer
AvionicsApplication
Proposed Approach
OperatingSystemGeneralPurpose
Computer
OperatingSystemGeneralPurpose
Computer
AvionicsApplication
AvionicsApplication
High Speed Data Bus
OperatingSystemGeneralPurpose
Computer
AvionicsApplication
ReconfigurableFail-StopAvionics
Application
High Speed Data Bus
Assured Reconfiguration 20May 2005
UVA Dependability Research Group
FaultDetection
AndSignalingSystem
Distributed Reconfigurable System Architecture
BIU
OperatingSystemGeneralPurpose
ComputerBIU
OperatingSystemGeneralPurpose
ComputerBIU
OperatingSystemGeneralPurpose
ComputerBIU
SpecialPurposeDevice
AvionicsApplication
AvionicsApplication
AvionicsApplication
High Speed Data Bus
Subsystem Control ReconfigurationAnalysis & Management (SCRAM) Software
Crucial Software
Assured Reconfiguration 21May 2005
UVA Dependability Research Group
Crucial Software Development
SCRAM Software (Common)
State Machine Specification (System Specific)
Analysis & Synthesis
Reconfiguration Specification
Reconfiguration Definition
Equivalence ProofOne
Man
y
Assured Reconfiguration 22May 2005
UVA Dependability Research Group
Application Programming
Assured Reconfiguration 23May 2005
UVA Dependability Research Group
Fail-Stop Processors
Introduced by Schlichting and SchneiderBuilding block for critical systemsFail-stop processor:
Processing unitsVolatile storageStable storage
Stable storage preserved on failure
Assured Reconfiguration 24May 2005
UVA Dependability Research Group
Reconfigurable FTAsFault-tolerant actions (FTAs)
In S&S work, recovery must complete original action In our work, recovery could be reconfiguration
Complete some different function
Action Action Recovery
Action Action Recovery:Reconfiguration
Assured Reconfiguration 25May 2005
UVA Dependability Research Group
Reconfigurable Fail-Stop SystemsSoftware building block is a reconfigurable applicationReconfigurable application has:
A predetermined set of specificationsA predetermined set of FTAs for each specification
Application function exists in system context:Recovery must be appropriate to systemFailure in one application could cause failure in another
Not a problem in S&S work since failures were masked, sufficient resources assumed
Assured Reconfiguration 26May 2005
UVA Dependability Research Group
Application and System FTAs
Application FTAsExecution of a single application
System FTAsComposed of a set of AFTAs
Affected applications’ actions and recovery protocolsStandard AFTAs for the other applications
Coordinates stages of AFTAsStages have time boundsS & S can guarantee livenessSafe configuration enables real-time guarantees
Assured Reconfiguration 27May 2005
UVA Dependability Research Group
Reconfiguration Software Architecture
SpecificationsSi,1: desired
functionalitySi,2: intermediate
functionality…Si,m: crucial
functionality
System calls
Subsystem Control Reconfiguration Analysis & Management Software
System calls
Reconfiguration Signals
Reconfiguration Signals
Hardware fault signals
Software fault
signals
Operating System
Computing Platform – Processing Units, Communications Facilities, Network Support, Sensors, Etc.
Application 1 Application N
S1,2S1,1 SN,1
S1,kSN,2 SN,l
Assured Reconfiguration 28May 2005
UVA Dependability Research Group
Reconfiguration Assurance
Assured Reconfiguration 29May 2005
UVA Dependability Research Group
Reconfiguration PropertiesReconfiguration:
Begins with a signal generated by some applicationEnds either with a second signal, or when all applications have finished initialization
The new configuration is appropriate for the circumstancesAll reconfigurations complete within their required time boundThe system invariant holds during reconfigurationAdditional restriction on sequences of reconfiguration signals
Assured Reconfiguration 30May 2005
UVA Dependability Research Group
Assurance TechnologyBased on PVS specification notation and PVS theorem-proving systemPVS:
Language is a higher-order logic based on type theorySubtypes are defined by adding a predicate to a supertypePredicate must hold over any instance of subtypeType properties can be used in proofsIn some cases, type properties are undecidableProduces type-correctness conditions (TCCs), a kind of proof obligationPVS system mechanically checks proofs
Assured Reconfiguration 31May 2005
UVA Dependability Research Group
Proof StructureReconfiguration Properties
Interaction Specification(State Sequences)
ApplicationAbstract Specification
Reusable PVS Proof Using Type Constraints
System-specific Proofby Type System
ApplicationSpecification Instances
Abstract Reconfiguration Specification
ReconfigurationSpecification InstanceSystem-
SpecificConfiguration,Environment,
TransitionInformation
UsedIn
Assured Reconfiguration 32May 2005
UVA Dependability Research Group
Reconfiguration Specification
System applications
Operating environment
System configurations
System transitions
Valid system implementation generates a valid sequence of system states
Assured Reconfiguration 33May 2005
UVA Dependability Research Group
Proof SampleProofs are scripts that can be mechanically checked using the PVS systemassured_reconfig.CP5: proved - complete [shostak](13048.43 s)
(""(skosimp)(split)(("1"(lemma "reconf_length")(inst -1 "s!1" "r!1")(typepred "r!1")(typepred "s!1`tr")(expand "get_reconfigs")(hide -2 -3 -4)(flatten)(case "r!1`end_c - r!1`start_c = 1")(("1"(lemma "reconf_halt")(expand "reconfig_end?")(split -6)(("1"(expand "reconfig_start?")(skosimp)(inst -1 "app!1")(inst -2 "s!1" "r!1" "app!1")(hide -4 -5 -6 -7 -8)(grind))("2" (propax))))
("2"
Assured Reconfiguration 34May 2005
UVA Dependability Research Group
Reconfiguration Example
Assured Reconfiguration 35May 2005
UVA Dependability Research Group
ExampleUAV systemFour applications:
Sensors, flight control systemAutopilot, pilot interface
Complete reconfiguration interface, multiple functionalitiesThree reconfiguration triggers:
Electrical powerRudderAutopilot
Assured Reconfiguration 36May 2005
UVA Dependability Research Group
Example Configurations
adjusting for rudder
disabledhard-over left/right
batteryRudder Hard-Over L/R, Flight Control Only
adjusting for rudder
nonfunctionalhard-over left/right
alternatorRudder Hard-Over L/R, Flight Control Only
adjusting for rudder
altitude hold only
hard-over left/right
alternatorRudder Hard-Over L/R, Altitude Hold Only
adjusting for rudder
normalhard-over left/right
alternatorRudder Hard-Over L/R
normaldisabledworkingbatteryFlight Control Only
normalnonfunctionalworkingalternatorFlight Control Only
normalaltitude hold only
workingalternatorAltitude Hold Only
normalnormalworkingalternatorFull Service
FCSAutopilotRudderPowerConfiguration
Assured Reconfiguration 37May 2005
UVA Dependability Research Group
Example SFTAIn Full Service configuration when the rudder
becomes stuck hard-over to the left
All apps:invariant
All apps:normal execution
4 (end)
FCS:transition condition
All other apps:invariant
FCS:prepare to adjust for rudder
All other apps:normal execution
3
App postconditionsApps anticipate possible reconfiguration2
Sensors: invariantAll other apps:
invariant
Sensors: signal generatedAll other apps:
normal execution
1 (start)PredicateActionFrame
Assured Reconfiguration 38May 2005
UVA Dependability Research Group
Example Status
Specified in PVSType-checked against the abstract specification75 TCCs generated
Most resulted from specific PVS approachMost others trivial to proveNontrivial proofs could be generated using state-space searchProofs could be more difficult for larger systems
Proof obligations dischargedReconfiguration properties hold
Assured Reconfiguration 39May 2005
UVA Dependability Research Group
ConclusionExploit potential of fully distributed targetHardware MTBFs:
Much higherLess replication needed, accept rare failures
Software Volume:Increasing and assurance remains difficultFail-stop software less difficult to develop
Base architecture on assured reconfigurationAssurance via comprehensive formal proof
Assured Reconfiguration 40May 2005
UVA Dependability Research Group
Contact Information
John Knight – [email protected] Strunk – [email protected] available at:
http://www.cs.virginia.edu/~jck/recentpapers.htm