Design methodologies

120  Download (0)

전체 글

(1)

9. System design techniques

aDesign methodologies.

aRequirements and specification.

(2)

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.

(3)

T i l ifi ti

Typical specifications

aFunctionality

aManufacturing cost aPerformance

aPerformance

(4)

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

(5)

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

(6)

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.

(7)

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.

(8)

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.

(9)

MCO S

MCO Scope

(10)

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.

(11)

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.

(12)

MPL S

MPL Scope

(13)

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

(14)

P j t M t Project Management

So What Went Wrong?

(15)

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

(16)

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

(17)

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 ,

(18)

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.

(19)

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

(20)

Design complexity vs.

designer productivity

(21)

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.

(22)

W t f ll d i l d l

Waterfall and spiral models

(23)

W t f ll d l Waterfall model

aEarly model for software development:

requirements

architecture

coding

testing testing

(24)

W t f ll d l

Waterfall model

(25)

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.

(26)

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.

(27)

S i l d l Spiral model

system feasibility ifi i

specification prototype prototype

initial system

req irements

enhanced system

requirements design

test

(28)

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.

(29)

S i l d l

Spiral model

(30)

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.

(31)

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

(32)

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.

(33)

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.

(34)

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

(35)

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.

(36)

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.

(37)

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.

(38)

Iterative Approach:

It ti

Iterations

(39)

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.

(40)

Iterative Approach:

Disciplines

(41)

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,

(42)

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

(43)

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.

(44)

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.

(45)

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

(46)

H d d i fl

Hardware design flow

(47)

Hardware/software d i fl

co-design flow

(48)

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

(49)

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.

(50)

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

(51)

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.

(52)

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.

(53)

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

(54)

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.

(55)

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

(56)

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

(57)

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.

(58)

C t

Current process

(59)

N

New process

(60)

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.

(61)

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.

(62)

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.

(63)

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.

(64)

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

(65)

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.

(66)

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.

(67)

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.

(68)

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.

(69)

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.

(70)

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

(71)

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.

(72)

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

(73)

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.

(74)

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.

(75)

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;

(76)

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.

(77)

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.

(78)

SDL SDL

a Used in

telecommunications

telephone

on-hook state

telecommunications protocol design.

a E t i t d t t

caller goes

ff 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

(79)

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

(80)

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.

(81)

SDL-representation of FSM /

FSMs/processes

state input state

output

(82)

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:

(83)

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-

(84)

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:

,

(85)

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.

(86)

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

(87)

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

(88)

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

(89)

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

(90)

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

(91)

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.

(92)

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.

(93)

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.

(94)

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

(95)

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.

(96)

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.

(97)

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.

(98)

T t t it t k Treatment monitor task

aTreat was main monitor task.

`Eight subroutines.

`Treat rescheduled itself after every y

subroutine.

(99)

T t t it t k

Treatment monitor task

(100)

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.

(101)

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

(102)

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.

(103)

Th 25 Therac-25

Low energy mode 200 rads electrons

HIgh energy mode 25 Mev x-ray

(104)

Th 25 f lt

Therac-25 fault

(105)

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

(106)

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)

(107)

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

(108)

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

(109)

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

(110)

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

(111)

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

(112)

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

(113)

Verifying requirements and ifi ti

specification

aRequirements:

`prototypes;

`prototyping languages; p yp g g g ;

`pre-existing systems.

aSpecifications:

aSpecifications:

`usage scenarios;

`formal techniques.

(114)

D i i

Design review

aUses meetings to catch design flaws.

`Simple, low-cost.

`Proven by experiments to be effective. y p

aUse other people in the project/company to help spot design problems

to help spot design problems.

(115)

D i i l

Design review players

aDesigners: present design to rest of team,

k h

make changes.

aReview leader: coordinates process. p

aReview scribe: takes notes of meetings.

aR i di l k f b

aReview audience: looks for bugs.

(116)

B f th d i i

Before the design review

aDesign team prepares documents used to d ib th d i

describe the design.

aLeader recruits audience, coordinates , meetings, distributes handouts, etc.

aAudience members familiarize themselves aAudience members familiarize themselves

with the documents before they go to the

meeting.

(117)

D i i ti

Design review meeting

aLeader keeps meeting moving; scribe

t k t

takes notes.

aDesigners present the design: g p g

`use handouts;

`explain what is going on;

`explain what is going on;

`go through details.

(118)

D i i di

Design review audience

aLook for any problems:

`Is the design consistent with the specification?

`Is the interface correct?

`How well is the component’s internal

`How well is the component s internal architecture designed?

`Did they use good design/coding practices?

`Did they use good design/coding practices?

`Is the testing strategy adequate?

(119)

F ll

Follow-up

aDesigners make suggested changes.

`Document changes.

aLeader checks on results of changes, may aLeader checks on results of changes, may

distribute to audience for further review or additional reviews

or additional reviews.

(120)

M t Measurements

aMeasurements help ground our beliefs:

`Do our practices really work?

`Do they work where we think they work? y y

aTypes of measurements:

`bugs found at different stages of design;

`bugs found at different stages of design;

`bugs as a function of time;

`bugs in different types of components;

`how bugs are found.

`how bugs are found.

수치

Updating...

참조

관련 주제 :