We use cookies to give you the best experience possible. By continuing we’ll assume you’re on board with our cookie policy

See Pricing

What's Your Topic?

Hire a Professional Writer Now

The input space is limited by 250 symbols

What's Your Deadline?

Choose 3 Hours or More.
Back
2/4 steps

How Many Pages?

Back
3/4 steps

Sign Up and See Pricing

"You must agree to out terms of services and privacy policy"
Back
Get Offer

Software Engineering for Dependable Systems

Hire a Professional Writer Now

The input space is limited by 250 symbols

Deadline:2 days left
"You must agree to out terms of services and privacy policy"
Write my paper

Software Engineering for Dependable Systems

Abstract

Don't use plagiarized sources. Get Your Custom Essay on
Software Engineering for Dependable Systems
Just from $13,9/Page
Get custom paper

Systems created to support, or whose human life depend upon are critical systems. Their failure could threaten human life, or the existence of the system environment that operates the system.  More and more medical instruments now include embedded control software. The systems are often understandable since they are smaller compared to industrial control systems. These software systems are often critical systems as a patients life may depend on them. In this course work project I will be looking at insulin pump as an example to represent safety –critical systems.

Insulin Pump

The insulin pump system is a portable, automated insulin pump which is used to administer insulin by diabetics. People with diabetes usually cannot make their own insulin (a hormone that is normally secreted by the pancreas) and is essential in sugar metabolism to generate energy. A personal insulin pump is an external device that mimics the function of the pancreas. It uses an embedded sensor to measure the blood sugar level at periodic intervals and then injects insulin to maintain the blood sugar at a ‘normal’ level.

The insulin pump hardware components

The insulin pump hardware components consists of Controller, Clock, Simulator, Display, Insulin Pump, Insulin Reservoir, Needle Assembly, Sensor, alarm and Power Supply.

The diagram below show the relationships between the hardware components and how they work.

Software

 The overall approach used to produce the insulin pump software was to emulate the

hardware organisation by producing separate software objects, for each

distinguishable hardware object. Of all of these software objects the controller object is

where the bulk of the computation within the system is carried.

It is within the controller that the dose of insulin to be delivered is computed and where the self tests are performed. Working in together with the controller object there is a clock object which runs in a thread, constantly determining how much time has lapsed since the software was started or the timer was reset (which happens every 24 hours). Then periodically, at every interval specified the clock triggers certain events required to be performed by the system.

A software called display is used to create a graphical user interface to present information to the user. The data is then presented to the user via text boxes positioned on the graphical user interface. The other software objects model the peripheral hardware units. They record the current state of the hardware units and provide the functionality to change that state.

All the mentioned objects combine together to produce the working insulin pump system.

In addition, one other object (the simulator software object) is also provided. This object runs in a thread parallel to the insulin pump software and provides the user with the functionality to perform a simulation of the real world events that would affect the pump software in differing manners. It facilitates the testing process, making it possible to perform the necessary testing required to determine whether the insulin pump system is adequately safe.

The make up of the objects within the system is detailed below by the object classes. The objects are represented by three sections:

The name of the object class
The class attributes
The operations associated with object class

the following sequence diagrams Illustrates the sequence of object interactions that occur in the insulin pump software. The diagram assumes that a reading has already been given to the Sensor object before the clock begins the sequence of interactions.

The final two sequences show how information that is intent to be output to the user is

initially passed to the clock object where it is stored in a buffer.  The contents of this buffer are then continually displayed to the user one after another for a period of five seconds each.

Sequence of object interactions involved in the manual delivery of insulin

If the user decides to operate the insulin pump manually, then he can do so. But the user must determine how much insulin he/she would wish to administer in his/her blood system.

This diagram shows that the user must input how much insulin they wish to administer after he/she has switched the insulin pump system to the manual mode, this is done

so by pressing the AdministerInsulinBut button as many times as is required in a five

second period.

Concept of operation

The embedden sensor gives the readings after  automatically measuring  the level of glucose in the patient’s body. Consecutive readings r0, r1 and r2 are compared and, if they indicate that the level of glucose is rising then insulin is injected to counteract this rise. R2 is the variable for the current reading, while r1 is the last reading and r0 being the previous reading.

The ideal situation is a level of sugar that is consistent within some ‘safe’ band.

Sugar levels

Unsafe

A very low level of sugar is dangerous and can result in hypoglaecemia which can result in a diabetic coma and ultimately death. An arbitrary figure of 3 units can be considered the minimum unit the body needs.

Safe

Between 3 units and about 7 units, the levels of sugar are ‘safe’ and are comparable to those in people without diabetes. This is the ideal band.

Undesirable

When the level of sugar rises above the limit of safe level, it is said to be undesirable.

 Levels above 7 units of insulin are undesirable but high levels are not dangerous in the short-term. Continuous high-levels however can result in long-term side-effects such as kidney damage, eye damage etc.

Insulin injection

The decision when to apply insulin does NOT depend on the absolute level of glucose that is measured in the sufferer’s blood. The reason for this is that insulin does not act instantaneously and the change in sugar level does not simply depend on a single injection but also on previous injections.

A more complex decision based on previous levels and rate of change of sugar level is used.

Injection scenarios

When the Level of sugar is in the unsafe band

The system should not inject insulin;

The system should initiate warning for the sufferer.

When the level of sugar is falling

The system should not inject insulin if in safe band.  It should inject insulin if rate of change of level is decreasing.

When the level of sugar is stable

The system should not inject insulin if level is in the safe band;

It should inject insulin if level is in the undesirable band to bring down glucose level;

The amount injected should be proportionate to the degree of undesirability i.e. inject more if level is 20 rather than 10.

Injection scenarios

When the level of sugar is increasing and the

Reading is in unsafe band

There should be no injection.

If the reading is in safe band

There should be an injection only if the rate of increase is constant or increasing. If constant, the injection should be standard amount; if increasing, compute amount based on increase.

Reading in unsafe band

Inject constant amount if rate of increase is constant or decreasing.

Otherwise inject computed amount if rate of increase is increasing.

Attributes of critical systems

Critical systems need to be available since lives or businesses depend on them. Lack of  availability would cause many hazards or dangers. The Insulin Pump software is a critical software system; it therefore must have the dependability attributes of a critical system. The insulin pump must have high levels of availability, reliability, safety and security.

Since the service requirement of the insulin pump is intermittent, we cannot talk about its being available always. In addition to that, delivery failure of insulin on a single occasion is not a problem although failure for a few hours would have an effect on the patient’s health. Since the machine software can be reset by switching on and off, the recovery of software errors is possible without compromising the usefulness and availability of the system due to its software breakdown. Otherwise it would take along time away from the user for repair.  Incase of hardware failure, the machine would be returned to the manufacturer. It would imply loss of availability of at least 3 days.

Reliability

The demands of this system are intermittent and it must be able to respond to these demands. We therefore talk about the probability of failure to respond to the demands. In this case we talk about two types of system failure, transient failure and permanent failure. Transient failures can be repaired by user actions such as resetting or recalibrating the pump. In this case a relatively low value of POFOD may be acceptable. About one failure in every four days. For permanent failures, the POFOD value should be very small. About once in every year.

Hazard analysis

Some hazards result from the failure of some physical failure of the system. These type of hazards are said to physical hazards. For example parts of the machine break off in the patient’s body. Hazards caused by electrical failure are referred to as electrical hazards e.g. power failure; machine interferes with electrically with other medical equipments such as heart pacemaker. Biological hazards result from some system failure that interfere with biological processes for example insulin overdose or under dose, infection caused by introduction of machine or allergic reaction to the materials or insulin used in the machine. Insulin overdose or insulin under dose can be the result of errors made by the software in computing the dose required. They are software related hazards. All other hazards are related to the hardware and physical design of the machine.

Risk analysis example

Software problems (errors)

There are two types of software errors namely Arithmetic error and algorithmic error. Some arithmetic computations cause representation failure. Specification may state that arithmetic error must be detected and an exception handler included for each arithmetic error and the action taken for these errors should be defined. Algorithmic errors are difficult to detect. Realism checks could be used on computed dose of insulin

General dependability requirements

The system shall not deliver a daily cumulative dose of insulin that is greater than a specified maximum for a system user.
The system shall not deliver a single dose of insulin that is greater than a specified maximum dose for a system user.
The system shall include a hardware diagnostic facility that should be executed at least 4 times per hour. The system shall include an exception handler for all of the
Exceptions identified
The audible alarm shall be sounded when any hardware anomaly is discovered and a diagnostic message a

Analysis of the insulin pump algorithm and the safety argument.

Algorithm to compute insulin dose

The following is the given algorithm for an automated insulin pump which I want to examine, analyze and produce safety argument in order to determine if it is adequately safe. When the insulin pump is in automatic mode, the software periodically determines (using the blood sugar level readings) the dose of insulin that should be administered to the user. This is the functionality provided by the insulin pump software that ensures the system is considered to be a safety critical system.

Before the blood sugar level is read in, a safety check is performed to determine that the

system status is correct and that the mode is set to Auto:

if (manDeliveryButPressed = = false)

{

if (status != ERROR && remainingInsulin >=

maxSingleDose && cumulativeDose < maxDailyDose)

{

If these requirements are met then the blood sugar level can be read in:

reading2 = Sensor.getReading();

Once the blood sugar level has been read in, the system must determine whether this level

represents that the sugar level is too low, at a safe level or is too high. In order to do this

the current reading is checked against the safe minimum and safe maximum blood levels

defined.

Check if sugar level is low:

if (reading2 < safeMin)

if sugar level is safe:

else if (reading2 >= safeMin && reading2 <= safeMax)

or if sugar level is too high:

else if (reading2 > safeMax)

Depending on the outcome of these tests, one of three execution paths is taken, they are:

Execution path if sugar level is low

compDose = 0;

alarm_ON = true;

status = WARNING;

pumpTimer.displayOutput(“Sugar Low”);

If the blood sugar level is less than the safe minimum then the dose computed to be

delivered is 0, the alarm is set to be activated, the status of the system is set to warning

and the user is displayed a warning message reading “Sugar Low”.

Execution path if sugar level is safe

If the sugar level is deemed to be safe then the current reading is compared against the

previous reading in order to determine whether, since the previous reading the blood

sugar level is stable or falling, if it is then the dose computed to be administered is set to

0:

if (reading2 <= reading1)

{

compDose = 0;

}

If this is not the case then the sugar level must be rising and a relative dose of insulin

must be calculated to attempt to prevent any further increase in the sugar level:

// If rate of increase is falling

if ((reading2 – reading1) < (reading1 – reading0))

{

compDose = 0;

}

// If rate of increase is increasing

else if ((reading2 – reading1) >= (reading1 – reading0))

{

// If dose is rounded to zero, deliver the min dose

if ((reading2 – reading1) / 4 == 0)

{

//set the amount to deliver to the min dose

compDose = minDose;

}

else if ((reading2 – reading1) / 4 > 0)

{

//Set the amount to deliver

compDose = (reading2 – reading1) / 4;

}

}

Once it has been determined that an increase has occurred, the first test the software

performs is to check whether the rate of increase is falling overall. If it is then the dose

computed to be administered is set to 0. Otherwise, the software then proceeds to ensure

that the rate is therefore increasing, if it is then a dose to be administered is computed

depending on the severity of the increase. If the rate of increase is not severe enough to

be rounded to higher number than 0 then the minimum dose is administered.

Execution path if sugar level is too high

If the sugar level is otherwise deemed to be too high the following code is executed:

// If Sugar level increasing

if (reading2 > reading1)

{

// If dose is rounded to zero, deliver the min dose

if ((reading2 – reading1) / 4 == 0)

{

compDose = minDose;

}

else if ((reading2 – reading1) / 4 > 0)

{

//Set the amount to deliver

compDose = (reading2 – reading1) / 4;

}

}

// If the Sugar level is stable

else if (reading2 == reading1)

{

compDose = minDose;

}

// If the Sugar level is falling

else if (reading2 < reading1)

{

// If rate of decrease increasing

if ((reading2 – reading1) <= (reading1 – reading0))

{

compDose = 0;

}

// If rate of decrease decreasing

else

{

compDose = minDose;

}

}

Again, the software determines whether the sugar level overall is increasing, decreasing

or whether the level has remained stable. The dose is calculated in the same manner as it

would be had the sugar level been safe, except when the sugar level high the software not

only checks whether the sugar level is falling but also checks the rate at which it’s falling.

If the rate of decrease is increasing then the computed dose is set to 0 whereas if the rate

of decrease is decreasing, the minimum dose of insulin is computed to be administered.

Also if the sugar level is too high, the software computes that the minimum dose should

be delivered if the level has remained stable.

Safety of the algorithm

It is very necessary for the system to determine whether the computed dose is safe

after the dose has been computed by the system. This is essential due to the critical nature of the software. We can use the safety argument method of validation to try and prove to a satisfactory level that the insulin pump software is safe; so that we can make certain that the insulin pump system cannot deliver an unsafe quantity of insulin. Therefore the section of code we must produce a safety argument for is the following:

//IF STATEMENT: 1

//If max daily dose will be exceeded by the dose calculated

if ((compDose + cumulativeDose) > maxDailyDose)

{

//Alert the user and set status to Warning

alarm_ON = true;

status = WARNING;

dose = maxDailyDose – cumulativeDose;

InsulinPump.deliverInsulin(dose);

pumpTimer.displayOutput(“Close to Max Daily Dose”);

}

//Normal situation

else if ((compDose + cumulativeDose) < maxDailyDose)

{

//IF STATEMENT: 2

if (compDose <= maxSingleDose)

{

dose = compDose;

InsulinPump.deliverInsulin(dose);

}

//If the single dose computed is too high

else

{

dose = maxSingleDose;

InsulinPump.deliverInsulin(dose);

}

}

There are two pre-conditions that would make the system unsafe;

a) If the dose calculated to be delivered is greater than the maximum single dose value

b) If the maximum daily dose was exceeded.

Using the safety argument we must prove that the all the if-statement post conditions

contradict the unsafe pre-condition:

Safety Argument

Using the fault tree analysis shown below will help see the faults or errors that can be found in the system

Results

The safety argument shows that the potentially unsafe state could be reached and there is a great possibility that a user could be administered the maximum daily amount of insulin in one go.

This would happen if this sequence of events were to occur:

 cumulativeDose = 0

 compDose computed to be a very high number

 If statement: 1 then branch executed

 dose = maxDailyDose – 0

 InsulinPump.deliverInsulin(dose)

Conclusion

From this safety argument I can conclude that the insulin pump software (if implemented according to the Z specification provided) is unsafe since the potentially unsafe state could be reached. The user could be administered the maximum daily amount of insulin in one go.

 The Z specification specifies that the dose should be administered as a post condition of If-statement: 1 (the requirement to administer the insulin at this point is modeled in the Z specification as dose!). In order to eliminate this safety error the point at which insulin is administered (dose!) would have to be moved in the specification.

References

Architecting dependable systems III: V. 3
by Rogério de Lemos, Cristina Gacek, Alexander Romanovsky – Computers – 2005

Component-Based Software Engineering: 10th International Symposium, CBSE  Page 156 by Heinz-W. Schmidt, Ivica Crnkovic, George T. Heineman, Judith A. Stafford – Computers – 2007 – 283 pages

Concurrency in Dependable Computing – Page 61 by Paul Ezhilchelvan, Alexander Romanovsky – Computers – 2002  chapter 4

Software for Dependable Systems: Sufficient Evidence? – Page 124
by Daniel Jackson, National Research Council (U.S.), National Academies Press, Martyn Thomas, Lynette I. Millett – Computers – 2007

Software Engineering Handbook – Page 361 Chapter 39 by Jessica Keyes – Computers – 2003

Software Engineering by Ian Sommerville – Computers – 2006
Part 4 and chapter 18

Structure for Dependability: Computer-Based Systems
by Denis Besnard, Cristina Gacek, Cliff Jones – Computers – 2005

Introduction to Fuzzy Reliability – Page 6 by Kai-Yuan Cai, Sushil Jajodia – Computers – 1996

SDI: technology, survivability, and software – Page 259

Software Engineering and Fault Tolerant Systems – Page 25
by P. Pelliccione, H. Muccini, N. Guelfi – Computers – 2007 – 281 pages

B. Nuseibeh and S. Easterbrook, Requirements Engineering

 

Cite this Software Engineering for Dependable Systems

Software Engineering for Dependable Systems. (2016, Oct 22). Retrieved from https://graduateway.com/software-engineering-for-dependable-systems/

Show less
  • Use multiple resourses when assembling your essay
  • Get help form professional writers when not sure you can do it yourself
  • Use Plagiarism Checker to double check your essay
  • Do not copy and paste free to download essays
Get plagiarism free essay

Search for essay samples now

Haven't found the Essay You Want?

Get my paper now

For Only $13.90/page