9. System design techniques
aDesign methodologies.
aRequirements and specification.
D i th d l i
Design methodologies
aProcess for creating a system.
aMany systems are complex:
`large specifications;
`large specifications;
`multiple designers;
`interface to manufacturing
`interface to manufacturing.
aProper processes improve:
`quality;
`cost of design and manufacture
`cost of design and manufacture.
T i l ifi ti
Typical specifications
aFunctionality
aManufacturing cost aPerformance
aPerformance
D i l Design process goals
a Time-to-market:
`beat competitors to market;p ;
`meet marketing window (back-to-school).
a Design cost. g a Quality
`Correctness
`Reliability
`Usability
a A good methodology is critical to building
systems that works properly
M Cli t Ob
Mars Climate Observer
a L t M i S t b 1999
a Lost on Mars in September 1999.
`Most likely exploded as it heated up in the atmosphere
atmosphere
a Requirements problem:
`Requirements did not specify units
`Requirements did not specify units.
`Lockheed (contractor) Martin used English : pound- force
force
`JPL (user) wanted metric: N
`1 pound-force ≡ 0.45359237 kg × 9.80665 m/s2p g /
= 4.45 N
= 32.17405 lbm·ft/s2
M Cli t O bit
Mars Climate Orbiter
a NASA started Mars Surveyor Program in 1993.
a Mars Climate Orbiter was launched on Dec. 11, 1998.
a Mars Climate Orbiter was launched on Dec. 11, 1998.
a Mars Polar Lander was launched on Jan. 3, 1999.
MCO S
MCO Scope
a Develop and launch two spacecrafts to Mars during the 1998 Mars transfer
Mars during the 1998 Mars transfer opportunity.
a Development cost was estimated at p
$183.9 Million.
a Collect and return to Earth, science data resulting from the water and remote
investigations of the Martian environment by the Lander
by the Lander.
MCO S
MCO Scope
a Orbiter should act as a relay station for five years relay station for five years.
a Assist in data transmission to and from the Mars Polar to and from the Mars Polar Lander.
a Provide detailed information about the atmospheric a Provide detailed information about the atmospheric
temperature, dust, water vapor, and clouds on Mars.
a Provide valuable information about the amount of a Provide valuable information about the amount of
carbon dioxide (CO2) in Mars.
MCO S
MCO Scope
A b ki
Aerobraking
a Aerobraking is a spaceflight technique wherein
biti ft b h i t th t f
an orbiting spacecraft brushes against the top of a planetary atmosphere.
a The friction of the atmosphere against the a The friction of the atmosphere against the
surface of the spacecraft slows down and lowers the craft's orbital altitude.
a The solar panels is are used to provide the maximum drag in a symmetrical position that
ll t l th ft
allows some control as the spacecraft passes
through the atmosphere.
MPL S
MPL Scope
a A second spacecraft Mars Polar Lander will be
launched.
a Perform daily recording of the
sound and images of Mars for one Martian year (687 g y ( days).
a The Purpose of the mission is to gather atmospheric data of each of the seasons on Mars.
a The mission's projected end date is December 1, 2004.
MPL S
MPL Scope
MCO C t MCO Cost
a A total of $327 6 million was allocated for the Mars ’98 a A total of $327.6 million was allocated for the Mars ’98
Project (which included the Mars Climate Orbiter and the Mars Polar Lander)
the Mars Polar Lander)
`$193.1 million for spacecraft development,
`$91 7 million for launch and
`$91.7 million for launch, and
`$42.8 million for mission operations
a $80M of the $193 1M went toward the building of the a $80M of the $193.1M went toward the building of the
MCO spacecraft
a $5M of the $42.8M used to operations the MCO a $5M of the $42.8M used to operations the MCO a $35.5M went toward the launching of the MCO
P j t M t Project Management
So What Went Wrong?
P j t M t Project Management
a The official report cited the following “contributing factors” to the loss of the spacecraftp
`undetected errors in ground-based models of the g spacecraft the
`the operational navigational team was not fully p g y
informed on the details of the way that Mars Climate Orbiter was pointed in space
`a final, optional engine firing to raise the spacecraft’s path relative to Mars before its arrival was considered
P j t M t Project Management
aSummary
`One Technical Problem
• failed conversion of unit
`Many Process and Social Problems
• No review (e.g. verification), insufficient ( g ),
training, informal processes in place, formal processes ignored
`
Led to a destroyed spacecraft
D i fl
Design flow
aDesign flow: sequence of steps in a design methodology
design methodology.
aMay be partially or fully automated.
`Use tools to transform, verify design.
aDesign flow is just one component of aDesign flow is just one component of
methodology.
h d l l l d
aMethodology also includes management
organization, etc. g ,
D i th d l
Design methodology
aDesign methodology: a procedure for
ti i l t ti f t f
creating an implementation from a set of requirements.
aMethodology is important in embedded computing:
computing:
`Must design many different systems.
`We may use same/similar components in
many different designs.
Embedded system design h ll
challenges
aDesign space is large and irregular.
aWe don’t have synthesis tools for many steps. p
aCan’t simulate everything.
aM d b ild i l
aMay need to build special-purpose simulators quickly. q y
aOften need to start software development
Design complexity vs.
designer productivity
B i d i th d l i
Basic design methodologies
aFigure out flow of decision-making.
aDetermine when bottom-up information is generated.
g
aDetermine when top-down decisions are made
made.
W t f ll d i l d l
Waterfall and spiral models
W t f ll d l Waterfall model
aEarly model for software development:
requirements
architecture
coding
testing testing
W t f ll d l
Waterfall model
W t f ll d l t
Waterfall model steps
aRequirements: determine basic h t i ti
characteristics.
aArchitecture: decompose into basic p modules.
aCoding: implement and integrate aCoding: implement and integrate.
aTesting: exercise and uncover bugs. g g
aMaintenance: deploy, fix bugs, upgrade.
W t f ll d l iti
Waterfall model critique
aUnrealisitic
aO l l l f db k d it ti
aOnly local feedback---may need iterations between coding and requirements, for
l example.
aDoesn’t integrate top-down and bottom- g p up design.
aJust for software development aJust for software development
`Assumes hardware is given.
S i l d l Spiral model
system feasibility ifi i
specification prototype prototype
initial system
req irements
enhanced system
requirements design
test
S i l d l Spiral model
a Assumes that several versions of the system will be bulit
be bulit.
a Successive refinement of system.
`Start with mock-ups, move through simple systems to full-scale systems.
a P id b f db k f i
a Provides bottom-up feedback from previous stages.
a Working through stages may take too much
time.
S i l d l
Spiral model
S i l M d l S t
Spiral Model Sectors
a Objective setting
`Specific objectives for the phase are identified
`Specific objectives for the phase are identified.
a Risk assessment and reduction
`Risks are assessed and activities put in place to
`Risks are assessed and activities put in place to reduce the key risks.
a Development and validationp
`A development model for the system is chosen which can be any of the generic models.
a Planning
`The project is reviewed and the next phase of the spiral is planned
spiral is planned.
S i fi t d l Successive refinement model
specify specify
architect architect
design build
design build build
test
build test initial system refined system
S i fi t d l Successive refinement model
a More make sense when you are unfamiliar to the application domain
the application domain.
a Successive refinement of system.
`Start with mock-ups, move through simple systems to full-scale systems.
a P id b f db k f i
a Provides bottom-up feedback from previous stages.
a Working through stages may take too much
time.
It ti A h Iterative Approach
aIn the iterative approach, the lifecycle
h d l d f th l i l
phases are decoupled from the logical software activities that occur in each phase, allowing us to revisit various
activities, such as requirements, design, activities, such as requirements, design, and implementation, during various
iterations of the project
iterations of the project.
Iterative Approach:
Lifecycle Phases
1. Inception phase
` The team is focused on understanding the
business case for the project, the scope of the j t d th f ibilit f
project, and the feasibility of an implementation.
` Problem analysis is performed the vision for the
` Problem analysis is performed, the vision for the solution is created, and preliminary estimates of schedule and budget, as well as project risk
schedule and budget, as well as project risk
Iterative Approach:
Lifecycle Phases
2. Elaboration phase
` The requirements for the system are refined, an
` The requirements for the system are refined, an initial, perhaps even executable, architecture is established, and an early feasibility prototype is typically developed and demonstrated.
Iterative Approach:
Lifecycle Phases
3. Construction phase
` The focus is on implementation.
` Most of the coding is done in this phase, and the architecture and design are fully developed.
Iterative Approach:
Lifecycle Phases
4 Transition phase 4. Transition phase
` Beta testing
` The users and maintainers of the system are
` The users and maintainers of the system are trained on the application.
` The tested baseline of the application is
` The tested baseline of the application is
transitioned to the user community and deployed for use.
Iterative Approach:
It ti
Iterations
Iterative Approach:
Iterations
a Within each phase, the project typically undergoes multiple iterations
multiple iterations.
a An iteration is a sequence of activities with an a An iteration is a sequence of activities with an
established plan and evaluation criteria, resulting in an executable of some type.
executable of some type.
a Each iteration builds on the functionality of the prior a Each iteration builds on the functionality of the prior
iteration; thus, the project is developed in an "iterative and incremental" fashion.
Iterative Approach:
Disciplines
Iterative Approach:
Disciplines
a In the iterative approach, the activities associated with the development of the software are organized p g into a set of disciplines.
a Each discipline consists of a logically related set of
activities, and each defines how the activities must be sequenced to produce a viable work product (or
sequenced to produce a viable work product (or artifact).
a Although the number and kind of disciplines can vary, based on the company or project circumstances,
Iterative Approach:
Disciplines
a During each iteration, the team spends as much time as appropriate in each discipline.
`Thus an iteration can be regarded as a mini-waterfall
`Thus, an iteration can be regarded as a mini waterfall
through the activities of requirements, analysis and design, and so on, but each mini-waterfall is "tuned" to the specific needs of that iteration.
a The size of the "hump" indicates the relative amount of effort invested in a discipline
of effort invested in a discipline.
`For example, in the elaboration phase, significant time is spent on "refining" the requirements and in defining the architecture that will support the functionality.
architecture that will support the functionality.
a The activities can be sequential (a true mini-waterfall) or may execute concurrently as is appropriate to the or may execute concurrently, as is appropriate to the
Requirements in the Iterative Model
aFrom the requirements management perspective the iterative approach
perspective, the iterative approach provides two major advantages:
1.Better adaptability to requirements change.
2.Better scope management.
M d li i h d
Modeling in hardware
aTechnology databases capture
f t i i f ti
manufacturing process information.
aCell libraries describe the cells used to compose designs.
aLogic synthesis systems use routability aLogic synthesis systems use routability
and timing models.
E b dd d t
Embedded system
aOften involve the design of hardware as
ll ft
well as software
requirements and requirements and
specification architecture architecture
hardware design software design
integration
H d d i fl
Hardware design flow
Hardware/software d i fl
co-design flow
C d i th d l
Co-design methodology
aMust architect hardware and software t th
together:
`provide sufficient resources;
`avoid software bottlenecks.
aCan build pieces somewhat aCan build pieces somewhat
independently, but integration is major t
step.
aAlso requires bottom-up feedback. q p
Hi hi l d i fl
Hierarchical design flow
aEmbedded systems must be designed lti l l l f b t ti
across multiple levels of abstraction:
`system architecture;
`hardware and software systems;
`hardware and software components
`hardware and software components.
aOften need design flows within design
flflows.
Hi hi l HW/SW fl
Hierarchical HW/SW flow
spec specspec
architecture HW architectureSW architecture HW SW detailed designdetailed design
integrate test
integration test
integration test test
system
test hardware
test software
C t i i
Concurrent engineering
a Large projects use many people from multiple disciplines.
a Work on several tasks at once to reduce design g time.
a Feedback between tasks helps improve quality a Feedback between tasks helps improve quality,
reduce number of later design problems.
a Tries to eliminate “over the wall” design steps a Tries to eliminate over-the-wall design steps
with little interaction between the two.
Concurrent engineering t h i
techniques
a Cross-functional teams: include members form various disciplines
disciplines
a Concurrent product realization: doing several things to a Concurrent product realization: doing several things to
reduce design time.
a Incremental information sharing: as soon as new
information is available, it is shared and integrated into g the design. Cross-functional teams are important to the effective sharing of information in a timely fashion.
Concurrent engineering t h i
techniques
a Integrated product management: ensures that someone g p g is responsible for the entire project, and that
responsibility is not abdicated once one aspect of the k i d
work is done.
l d l l l
a Early and continual supplier involvement a Early and continual customer focus
AT&T PBX concurrent
i i
engineering
a AT&T applied concurrent engineering to the designs of PBXs
a They re-engineered their process to reduce design time and make other improvement to the end product
a Th d t d ib d b l
a They used seven step process described below:
1. Benchmark against competitors.
2 Identify breakthrough improvements 2. Identify breakthrough improvements.
3. Characterize current process.
4. Create new process.p 5. Verify new process.
6. Implement.
7. Measure and improve.
AT&T PBX concurrent
i i
engineering
1 Benchmark against competitors 1. Benchmark against competitors.
` They found that it took them 30% longer to
introduce a new product than their best competitors introduce a new product than their best competitors.
` They decided to shoot for a 40% reduction in design time
time
2. Identify breakthrough improvements.
` Identify the factors that would influence their effort
` Identify the factors that would influence their effort
` Three major factors were identified:
` increased partnership between design and manufacturing,
` increased partnership between design and manufacturing,
` continued existence of the basic organization of design labs and manufacturing, and
AT&T PBX concurrent
i i
engineering
` As a result three groups were established to help manage effortg
` A steering committee formed by mid-level managers
` A project office formed by a manager and an operation l t
analyst
` A core team of engineers and analysts formed to make things happens g pp
3. Characterize the current process.
` They built flowcharts and identified several root y causes of delays
` Design and manufacturing tasks were performed ti ll
sequentially
AT&T PBX concurrent
i i
engineering
` Groups tended to focus on intermediate milestones related to their narrow job descriptions, rather than trying to take into account the effects of their decisions on other aspects into account the effects of their decisions on other aspects of the development
` Too much time was spent waiting in queues – jobs were handed off form one person to another very frequently In handed off form one person to another very frequently. In many cases, the recipient didn’t know how to best
prioritize the incoming tasks. It s a typical managerial bl
problem
` Too many groups has their own design databases,
creating redundant data that had to be maintained and creating redundant data that had to be maintained and synchronized.
C t
Current process
N
New process
AT&T PBX concurrent
i i
engineering
4. Creating the target process: Based on its studies, the core team created a new development process.
5. Very the new process: the team undertook a pilot product development project to test a new process
` M h i l l d PCB b d
` Mechanical enclosures and PCB boards
6. Implement across the product line
` This activity required training of personnel documentation of
` This activity required training of personnel, documentation of the new standards and procedures, and improvement to
information systems
7. Measure results and improve: the team found that
product development time had been reduced form 18- 30 months to 11 months
30 months to 11 months.
Pl tf b d d i
Platform-based design
a Platform includes
hardware supporting hardware, supporting software.
a T t
a Two stage process:
`Design the platform.
`Use the platform.
a Platform can be
reused to host many
different systems.
Pl tf d i
Platform design
a Turn system requirements and software models into detailed requirements
detailed requirements.
`Use profiling and analysis tools to measure existing executable specifications.
executable specifications.
a Explore the design space manually or automatically.p g p y y
a Optimize the system architecture based on the results of simulation and other steps.
a D l h d b t ti l d th ft
a Develop hardware abstraction layers and other software.
P i l tf
Programming platforms
a Programming environment must be customized to the platform:
platform:
`Multiple CPUs.
`Specialized memory
`Specialized memory.
`Specialized I/O devices.
a Libraries are often used to glue together processors on platforms.
platforms.
Standards-based design th d l i
methodologies
a Standards enable large markets.
a Standards generally allow products to be differentiated.
`Different implementations of operations so long as
`Different implementations of operations, so long as I/O behavior is maintained.
`User interface is often not standardized
`User interface is often not standardized.
a Standard may dictate certain non-functional a Standard may dictate certain non-functional
requirements (power consumption), implementation techniques.q
Reference
i l t ti
implementations
a Executable program that complies with the I/O behavior of the standard
behavior of the standard.
`May be written in a variety of language.
a I th f i l t ti i a In some cases, the reference implementation is
the most complete description of the standard.
a Reference implementation is often not well- suited to embedded system implementation:
`Single process.
`Infinite memory.
Designing standards-based t
systems
a Design and implement system components that are not part of the standard
are not part of the standard.
a Perform platform-independent optimizations.
a Analyze optimized version of reference a Analyze optimized version of reference
implementation.
a Design hardware platform a Design hardware platform.
a Optimize system software based on platform.
a F th ti i l tf
a Further optimize platform.
a Test for conformity to standard.
H 264/AVC H.264/AVC
aImplements video coding for a wide range f li ti
of applications:
`Broadcast and videoconferencing.
`Cell phone-sized screens to HDTV.
aVideo codec reference implementation aVideo codec reference implementation
contains 120,000 lines of C code.
Design verification and lid ti
validation
aTesting exercises an implementation by
l i i t d t ti t t
supplying inputs and testing outputs.
aValidation compares the implementation p p to a specification or requirements.
aVerification may be performed at any aVerification may be performed at any
design stage; compares design at one
level of abstraction to another.
Design verification t h i
techniques
aSimulation uses an executable model,
li i t
relies on inputs.
aFormal methods generate a (possibly g (p y specialized) proof.
aManual methods such as design reviews aManual methods, such as design reviews,
catch design errors informally.
A methodology of th d l i
methodologies
a Embedded systems include both hardware and software
software.
`HW, SW have their own design th d l i
methodologies.
a Embedded system methodologies control the overall process, HW/SW integration, etc.
`Must take into account the good and bad g
points of hardware and software design
methodologies used. g
Joint algorithm and
architecture development
aSome algorithm design is necessarily
f d b f l tf d i
performed before platform design.
aAlgorithm development can be informed g p by platform architecture design.
`Performance/power/cost trade offs
`Performance/power/cost trade-offs.
`Design trends over several generations.
R i t l i Requirements analysis
a Requirements: informal description of what customer wants
customer wants.
a Specification: precise description of what design t h ld d li
team should deliver.
a Requirements phase links customers with designers.
`marketing
T f i t Types of requirements
aFunctional: input/output relationships.
aNon-functional:
`timing;
`timing;
`power consumption;
`manufacturing cost;
`manufacturing cost;
`physical size;
`time-to-market;
`reliability.
`reliability.
G d i t Good requirements
a A good set of requirement should meet seven tests:
correctness, unambiguousness, completeness, , g , p , veriability, consistency, modifiability, traceability a Correctness: avoid over-requiring
a Unambiguousness: clear, only one interpretation a Completeness: all requirements should be included
a V ifi bilit th h ld b t ff ti t
a Verifiability: there should be a cost-effective way to ensure that each requirement is satisfied in the final system.y
`“attractive” : without some agreed definition
a Consistency: requirements should not contradict each th
other.
G d i t t’d Good requirements, cont’d.
a Modifiability: the requirement document should be
structured so that it can be modified to meet changing g g requirements without losing consistency, verifiabilty, etc.
a Traceability: each requirement should be traceable in the following ways
the following ways.
`trace backward to know why each requirement exists;
exists;
`trace forward to go from source documents (marketing memos) to requirements;
`trace forward to go from requirement to implementation;
S tti i t Setting requirements
a Customer interviews.
a Comparison with competitors a Comparison with competitors.
a Sales feedback.
a Mock ups prototypes a Mock-ups, prototypes.
a Next bench syndrome (HP): design a product for a Next-bench syndrome (HP): design a product for
someone like you.
`the ability to turn to the engineer at the next bench—or desk—
`the ability to turn to the engineer at the next bench or desk and ask what features they want.
S ifi ti
Specifications
a Capture functional and non-functional properties:
`verify correctness of spec;
`verify correctness of spec;
`compare spec to implementation.
a Many specification styles:
a Many specification styles:
`control-oriented vs. data-oriented;
`textual vs graphical
`textual vs. graphical.
a UML is one specification/design language.
SDL SDL
a Used in
telecommunications
telephone
on-hook state
telecommunications protocol design.
a E t i t d t t
caller goesff h k input
a Event-oriented state machine model.
dial tone
off-hook put
dial tone t t
caller gets t t state caller gets
dial tone output
SDL SDL
aLanguage designed for specification of distributed systems.
systems.
aDates back to early 70s,
aFormal semantics defined in the late 80s,
aD fi d b ITU (I t ti l T l i ti
aDefined by ITU (International Telecommunication Union): Z.100 recommendation in 1980
U d t i 1984 1988 1992 1996 d 1999
Updates in 1984, 1988, 1992, 1996 and 1999
SDL SDL
aProvides textual and graphical formats to please all users,
users,
aJust like StateCharts, it is based on the CFSM
d l f t ti h FSM i ll d
model of computation; each FSM is called a process,
aHowever, it uses message passing instead of shared memory for communications,
s a d o y o o u a o s,
aSDL supports operations on data.
SDL-representation of FSM /
FSMs/processes
state input state
output
O ti d t Operations on data
a Variables can be declared locally for processes.
a Their type can be predefined or defined in SDL a Their type can be predefined or defined in SDL
itself.
a SDL supports abstract data types (ADTs) a SDL supports abstract data types (ADTs).
Examples:
Communication among SDL FSM
SDL-FSMs
aCommunication between FSMs (or „processes“) is based on message-passing, assuming a potentially g p g, g p y indefinitely large FIFO-queue.
• Each process fetches next entry from FIFO,
• checks if input enableschecks if input enables transition,
• if yes: transition takes place
place,
• if no: input is ignored (exception: SAVE-
Process interaction di
diagrams
aInteraction between processes can be described in process interaction diagrams (special case of
block diagrams).
aIn addition to processes, these diagrams contain p , g channels and declarations of local signals.
aExample:
aExample:
,
St t h t Statecharts
aAncestor of UML state diagrams.
aProvided composite states:
`OR states;
`OR states;
`AND states.
aC it t t d th i f th aComposite states reduce the size of the
state transition graph.
St t h t OR t t Statechart OR state
s123 S1
i1
S1 i1 s123
i1
i2 S1
i1 i2
S2 i2 S4
S2 S4
i1 i2
i2
S3 S3
St t h t AND t t Statechart AND state
S1 3 S1 4
c sab
S1-3 S1-4
d b a b
S1 S3
S2-3 S2-4
b a
c
b a
c d
b a
S2 3 S2 4
S5
d r S2 S4
S5 traditional
r
AND OR t bl
AND-OR tables
aAlternate way of specifying complex conditions:
conditions:
cond1 or (cond2 and !cond3)
OR
cond1 T -
d2 T
AND
OR
cond2 - T
cond3 - F
AND
CRC d CRC cards
aWell-known method for analyzing a
t d d l i hit t
system and developing an architecture.
aCRC:
`classes;
`responsibilities of each class;
`responsibilities of each class;
`collaborators are other classes that work with l
a class.
aTeam-oriented methodology. gy
CRC d f t CRC card format
Class name: Class name:
Class name:
Superclasses:
Subclasses:
Responsibilities: Collaborators:
Class name:
Class’s function:
Attributes:
Responsibilities: Collaborators:
f t b k
front back
CRC th d l
CRC methodology
aDevelop an initial list of classes.
`Simple description is OK.
`Team members should discuss their choices.
aWrite initial responsibilities/collaborators.
`Helps to define the classes
`Helps to define the classes.
aCreate some usage scenarios.
`Major uses of system and classes.
CRC th d l t’d CRC methodology, cont’d.
aWalk through scenarios.
`See what works and doesn’t work.
aRefine the classes, responsibilities, and aRefine the classes, responsibilities, and
collaborators.
aAdd class relatoinships:
aAdd class relatoinships:
`superclass, subclass.
CRC d f l t
CRC cards for elevator
aReal-world classes:
`elevator car, passenger, floor control, car control, car sensor.
aArchitectural classes:
`car state floor control reader car control
`car state, floor control reader, car control
reader, car control sender, scheduler.
Elevator responsibilities d ll b t
and collaborators
class responsibilities collaborators
El t * M d d C t l
Elevator car* Move up and down Car control, car sensor, car control sender
sender Passenger* Pushed floor
control and car Car control, floor control Floor control* Transmits floor
requests Passenger, floor control reader Car state Records current
position of car Scheduler, car sensor
Q lit
Quality assurance
aQuality judged by how well product ti fi it i t d d f ti
satisfies its intended function.
`May be measured in different ways for different kinds of products.
aQuality assurance (QA) makes sure that aQuality assurance (QA) makes sure that
all stages of the design process help to deliver a quality product
deliver a quality product.
Therac-25 Medical Imager
(L d T )
(Leveson and Turner)
aSix known accidents: radiation overdoses
l di t d th d i i j
leading to death and serious injury.
aRadiation gun controlled by PDP-11. g y aFour major software components:
` t d d t
`stored data;
`scheduler;
`set of tasks;
`interrupt services
`interrupt services.
Th 25 t k Therac-25 tasks
aTreatment monitor controlled and
it d t d d li f t t t
monitored setup and delivery of treatment in eight phases.
aServo task controlled radiation gun.
aHousekeeper task took care of status aHousekeeper task took care of status
interlocks and limit checks.
T t t it t k Treatment monitor task
aTreat was main monitor task.
`Eight subroutines.
`Treat rescheduled itself after every y
subroutine.
T t t it t k
Treatment monitor task
S ft ti i
Software timing race
aTiming-dependent use of mode and energy:
`if keyboard handler sets completion behavior
before operator changes mode/energy data,
Datent task will not detect the change, but
Hand task will.
S ft ti i
Software timing errors
aChanges to parameters made by operator
h b t t b d b
may show on screen but not be sensed by Datent task.
aOne accident caused by entering
mode/energy changing mode/energy mode/energy, changing mode/energy, returning to command line in 8 seconds.
aSkilled operators typed faster, more likely
to exercise bug. g
Leveson and Turner
b ti
observations
aPerformed limited safety analysis:
d t b biliti t
guessed at error probabilities, etc.
aDid not use mechanical backups to check p machine operation.
aUsed overly complex programs written in aUsed overly complex programs written in
unreliable styles.
Th 25 Therac-25
Low energy mode 200 rads electrons
HIgh energy mode 25 Mev x-ray
Th 25 f lt
Therac-25 fault
Consequences of the over ddosage
1 The breast was removed, complete loss of arm and shoulder mobility and constant pain
2 Patient severely burned, died November 1985
3 Tissue necrosis, chronic ulcerations and pain in the treated area and several skin grafts were made and the patient is alive today (1995) 4 Pain in neck and shoulders, periodic nausea and vomiting, radiation
induced myelitis of the cervical cord paralysis of the left arm and both induced myelitis of the cervical cord, paralysis of the left arm and both legs, left vocal cord and left diaphragm
Died after five months due to the complications 5 Patient died one month later
Characteristics of the id t
accidents
a Three cases involved carousel rotation prior to treatment (confirmed)
a The accelerator malfunctioned shortly after “beam on”, reporting a malfunction code at the console
`The codes were cryptic and not recognized by the operator as e codes e e c ypt c a d ot ecog ed by t e ope ato as indicating a serious error
a In several cases, the operator repeated the exposure one or more times
one or more times
a Following treatment, the patients complained of burning sensations, sometimes accompanied by a feeling of
electric shock electric shock
a In each case, the patients received doses of between 4 and 25 KRADs in a very brief exposure (1-3 seconds)
Summary of causes of accidental exposure
a Manufacturer recycled software
`Earlier model functioned somewhat differently, so software was t ti l it bl
not entirely suitable
`Newer model relied entirely on software for safety, whereas older model had mechanical and electrical interlocks
`Th f t f th t t l t d h l
`The safety of the newer system was not evaluated as a whole, only the hardware was evaluated since software had been in use for years…
a The manufacturer had no mechanism for investigating a The manufacturer had no mechanism for investigating
and reporting accidents
`After the first accident, the manufacturer refused to believe the equipment was at fault
equipment was at fault
`The FDA was not notified, nor were other users
`The vendor kept their opinion that this machine was safe
Lessons: Suggested by computer science consultants
a Documentation key from beginning
`Use established software engineering practices
`Use established software engineering practices
`Keep designs simple
`Build in software error logging & audit trails
a Extensive software testing and formal analysis at all levels
`Revalidate re used software
`Revalidate re-used software
a Don’t rely only on software for safety a Do incorporate redundancy
a Do incorporate redundancy
a Pay careful attention to human factors a Involve users at all phases
a Involve users at all phases
Th ti ti
The continuation
a The 11 machines were refitted
with the safety devices required by the FDA and remained in service the FDA and remained in service a No more accidents were reported
from these machines
a After the Therac-25 deaths, the FDA made a number of
adjustments to its policies in an adjustments to its policies in an attempt to address the
breakdowns in communication and product approval.
`In 1990, health care facilities were
ISO 9000 ISO 9000
aDeveloped by International Standards i ti
organization.
aApplies to a broad range industries. pp g aConcentrates on process.
aV lid i b d i
aValidation based on extensive
documentation of organization’s process. g p
CMU Capability Maturity M d l
Model
aFive levels of organizational maturity:
`Initial: poorly organized process, depends on individuals.
`Repeatable: basic tracking mechanisms.
`Defined: processes documented and
`Defined: processes documented and standardized.
`Managed: makes detailed measurements
`Managed: makes detailed measurements.
`Optimizing: measurements used for
V ifi ti
Verification
aVerification and testing are important th h t th d i fl
throughout the design flow.
aEarly bugs are more expensive to fix: y g p
requirements
st to fix requirements
cos bug
coding bug
