Validasi System Kritis

SISTEM KRITIS

Yaitu Sistem yang apabila terjadi kegagalan, maka dapat mengakibatkan kerugian ekonomi yang besar, kerusakan fisik atau mengancam hidup manusia.

Ada 3 tipe utama sistem kritis

Sistem kritis dalam hal keselamatan

Sistem yang kegagalannya dapat mengakibatkan cedera, kematian atau kerusakan lingkungan. Contoh : sistem kendali untuk pabrik kimia

Sistem kritis dalam hal misi

Kegagalannya dapat mengakibatkan kegagalan pada suatu kegiatan yang diarahkan pada suatu tujuan. Contoh : Sistem navigasi pesawat udara

Sistem kritis dalam hal bisnis

Kegagalannya dapat mengakibatkan kegagalan pada bisnis yang menggunakan sistem tersebut. Contoh : Sistem rekening nasabah pada sebuah bank

Biaya Kegagalan Sistem

Langsung

Karena sistem harus diganti

Tidak langsung

Biaya proses pengadilan

Kerugian bisnis yang terjadi karena sistem tidak tersedia

Komponen sistem yang rentan terhadap kegagalan

Hardware: disebabkan karena :

Kesalahan dalam perancangan

Komponen rusak karena kesalahan manufaktur

Komponen telah mencapai akhir masa pakai

Software : karena kesalahan dalam perincian, perancangan, atau implementasi

Operator sistem : gagal menjalankan sistem dengan benar

Dependabilitas Sistem Kritis

Dependabilitas

Properti dari sistem

Sama dengan keterpercayaan (trustworthiness)

Yaitu derajad kepercayaan user bahwa sistem yang akan beroperasi sebagaimana yang mereka harapkan

Atau sistem tidak akan gagal dalam penggunaan yang normal

Dimensi dependabilitas :

Ketersediaan (Availability)

Probabilitas bahwa sistem dapat bekerja dan memberikan layanan yang berguna setiap saat

Keandalan (Reliability)

Probabilitas bahwa dalam jangka waktu tertentu bahwa sistem akan memberikan layanan dengan benar sesuai harapan user

Keselamatan (Safety)

Penilaian pada seberapa besar kemungkinan sistem akan menyebabkan kerusakan terhadap orang dan lingkungan sistem

Keamanan (Security)

Penilaian pada seberapa besar kemungkinan sistem dapat bertahan terhadap campur tangan yang disengaja atau tidak disengaja

Ada 3 dimensi dependabilitas yg berlaku

Ketersediaan :

Sistem hrs tersedia untuk memberikan insulin saat dibutuhkan

Keandalan :

Sistem hrs bekerja andal dan mengalirkan jumlah insulin yang tepat

Keselamatan :

Kegagalan sistem dapat mengakibatkan pemberian dosis yg berlebihan shg mengancam hidup pasien

KETERSEDIAAN & KEANDALAN Keandalan mencakup ketersediaan

Krn jika suatu layanan yg telah ditentukan tidak diberikan, maka sistem tidak akan berjalan sebagaimana mestinya

Namun ada sistem yg dapat mentolerir kegagalan yg relatif sering terjadi, namun memiliki persyaratan ketersediaan yg cukup tinggi ( cth : saklar hub telepon Jika sistem A gagal sekali setahun dan sistem B gagal sekali sebulan, maka A lebih dapat diandalkan dibanding B

Tetapi jika A membutuhkan 3 hari untuk dapat bekerja kembali sementara B membutuhkan 10 menit,maka ketersediaan B selama setahun jauh lebih besar ketimbang A Keandalan :

Probabilitsas sistem yg bebas dr kegagalan dlm kurun waktu tertentu pada suatulingkungan tertentu dan untuk tujuan yg tertentu pula

Ketersediaan :

Probabilitas bahwa suatu sistem pada suatu waktu akan bekerja dan dapat memberikan layanan yang diminta

Tiga pendekatan yg saling melengkapi yg dapat digunakan untuk memperbaiki keandalan sistem :

Penghindaran kesalahan

menghindari konstruksi bhs pemrograman yg rentan thd eror (pointer, rekursi, dll)

Deteksi dan buang kesalahan

Pengujian dan debug sistem

Toleransi kesalahan

Menjamin bahwa kesalahan sistem tidak menghasilkan eror atau menjamin bahwa eror sistem tidak mngakibatkan kegagalan Tidak semua kesalahn PL memiliki kemungkinan yang sama untuk mengakibatkan kegagalan PL

Sebuah program mungkin mengandung kesalahan yg diketahui namun tetap dapat diandalkan oleh usernya

User yg berpengalaman seringkali berputar menghindari kesalahan PL yg diketahui akan menyebabkan kegagalan.KESELAMATAN Yaitu atribut sistem yg merefleksikan kemampuan sistem untuk beroperasi secara normal atau abnormal tanpa membahayakan manusia atau lingkungan

Contoh : sistem kontrol dan monitor pada pesawat udara, sistem kontrol proses pada pabrik kimia dan farmasi, dan sistem kontrol pada mobilPL lunak yg kritis dalam hal keselamatan terbagi atas :

1. PL kritis keselamatan primer

PL yg menyatu sbg kontroler pada sistem

Malfungsi PL menyebabkan malfungsi PK

Menyebabkan cedera pada manusia atau kerusakan pada lingkungan

1. PL kritis keselamatan sekunder

PL yg secara tidak langsung dapat menimbulkan cedera

Cth : malfungsi sistem perancangan berbasis komputer yg mengakibatkan kesalahan pd objek yg dirancang

Fakta menunjukkan bahwa :

Kita tidak akan pernah 100% yakin bahwa suatu sistem PL bebas dari kesalahan dan bertoleransi terhadap kesalahanAda beberapa alasan lain mengapa sistem PL yg dapat diandalkan belum tentu menjamin keselamatan

1. Spesifikasi mungkin tidak lengkap

Tingkat persentase malfungsi sistem yg tinggi merupakan akibat dari eror spesifikasi, bukan eror perancangan.

1. Malfungsi perangkat keras

Shg menyebabkan PL menghasilkan suatu lingkungan yg tidak dapat diantisipasi

3. Operator sistem

Ada 3 hal yg perlu dilakukan utk menjamin bahwa kecelakaan tidak akan terjadi atau bahwa konsekuensi kecelakaan akan minimal, yaitu :

1. Menghindari bahaya

2. Deteksi dan membuang bahaya

Cth : sistem pabrik pengolahan bahan kimia yg dpt mendeteksi tekanan yg berlebihan dan akan membuka sebuah katup untuk mengurangi tekanan ini.

3. Membatasi kerusakan

Dgn menyertakan fitur proteksi yg akan meminimalisasi kerusakan

cth : pemadam api otomatis, sebelum melukai penumpang dan awak pesawatKEAMANAN Yaitu penilaian sampai sejauh mana sistem melindungi diri dari serangan eksternal yg disengaja atau tidak.

Contoh serangan : virus, penggunaan yg tidak syah atas layanan sistem, modifikasi yg tidak diijinkan thd data atau sistem

Cth sistem yg memerlukan jaminan keamanan tinggi : sistem militer, sistem e-commerce, dan sistem yg melibatkan pertukaran informasi rahasia

Ada 3 jenis kerusakan yg dapat disebabkan oleh serangan eksternal :

1. Penolakan layanan

Sehingga layanan normal sistem tidak tersedia

2. Korupsi program atau data

Karena perubahan komponen PL

3. Penyingkapan informasi rahasia

4. Keamanan semakin penting dgn beragamnya sistem yg terhubung dgn internet

5. Atribut yg yg terpenting utk utk sistem berbasis internet adalah kemampuan bertahan

6. Yaitu kemampuan sistem untuk terus meberikan layanan pada saat diserang atau pada saat sebagian sistem telah dilumpuhkan.

SPESIFIKASI SISTEM KRITIS Karena biaya potensi kegagalan sistem tinggi, maka penting untuk menjamin bahwa spesifikasi sistem kritis harus berkualitas tinggi dan dgn akurat merefleksikan kebutuhan user sistem yg sebenarnyaSpesifikasi keandalan PL Perlunya dependibilitas pd sistem kritis menimbukan :

Persyaratan fungsional

Dibuat utk mendefenisikan pemeriksaan eror dan fasilitas pemulihan serta fitur2 yg memberikan proteksi thd kegagalan sistem

Persyaratan non-fungsional

Untuk mendefenisikan keandalan dan ketersediaan sistem yg dibutuhkan Persyaratan lain yg hrs dipertimbangkan adalah persyaratan tidak akan, yaitu :

Sistem tidak akan memperbolehkan user mengubah ijin akses terhadap file manapun yg tidak mereka buat (keamanan)

Sistem tidak akan memperbolehkan dipilihnya metode mendorong ke belakang (reverse thrust mode) ketika pesawat sedang terbang (keselamatan)

Sistem tidak akan membolehkan aktivasi lebih dari tiga sinyal alarm secara bersamaan (keselamatan)

Ada 3 dimensi ketika menspesifikasikan keandalan sistem secara menyeluruh :

Keandalan PK

Keandalan PL

Keandalan operator

Kegagalan PK dpt menyebabkan sinyal palsu yg berada diluar kisaran input

Shg PL dp berprilaku spt yg tidak diharapkan

Prilaku sistem yg tidak diharapkan dpt membingungkan operator dan mengakibatkan stres operator

Eror operator sangat mungkin terjadi dalam kondisi stres, shg akan memberikan input yg tidak benar.Spesifikasi keselamatan PL Operasi yg selamat mrpk karakteristik yg dibutuhkan pada sistem PL yg berhubungan dgn keselamatan

Setiap bahaya harus dinilai terhadap resiko yg dimiliki

Selanjutnya mendeskripsikan bagaimana PL harus berprilaku utk meminimalisasi resiko atau mempersyratkan bahwa bahaya tidak boleh terjadiAnalisa biaya dan resiko Tujuannya utk menemukan bahaya potensial yg mungkin muncul, akar penyebab bahaya, dan resiko yg berhubungan dgnnya.

Proses iteratif dr analisis biaya dan resiko :

Identifikasi bahaya ( petir, gempa bumi, dll

Analisis resiko dan klasifikasi biaya

Penguraian bahaya ( penyebab

Penilaian reduksi resiko Pengurangan resiko :

Penghindaran bahaya

Sistem dirancang shg bahaya tidak muncul

Deteksi dan pembuangan bahaya

Sistem dirancang shg bahaya terdeteksi dan dinetralisasi sebelum menimbulkan kecelakaan

Pembatasan kerusakan

Sistem dirancang shg konsekuensi kecelakaan diminimalisasi

Spesifikasi Keamanan Tahap proses spesifikasi keamanan :

Identifikasi dan evaluasi aset (data dan program)

Analisis ancaman dan penilaian resiko

Penggolongan ancaman

Analisis teknologiPENGEMBANGAN SISTEM KRITIS Ada 2 pendekatan komplementer yg dapat dipakai jika tujuannya adalah mengembangkan PL yg dapat diandalkan :

Penghindaran kesalahan

Meminimalisasi eror manusia dan membantu menemukan kesalahan sistem sebelum sistem dipakai

Toleransi kesalahan

Sistem hrs dirancang sedemikian rupa shg kesalahan selama eksekusi akan terdeteksi dan tertangani.Minimalisasi Kesalahan PL yg bebas dr kesalahan adalah PL yg dgn tepat mengikuti spesifikasinya.

Namun PL yg bebas dr kesalahan belum tentu bebas dari kesalahanPersyaratan utk pengembangan PL yg bebas dr kesalahan :

1. Harus ada spesifikasi sistem yg tepat

2. Organisasi yg mengembangkan sistem hrs memiliki kultur kualitas organisasi

3. Hrs digunakan pendekatan perancangan dan implementasi PL yg berdasarkan penyembunyian informasi dan enkapsulasi

4. Gunakan bhs pemrograman yg strongly-typed (dpt mendeteksi kesalahan lebih banyak oleh kompilator)

5. Menghindari penulisan yg potensial rentan thd eror

6. Proses pengembangan hrs didefenisikan. Manajer kualitas hrs memeriksa kesesuaian prosesPenghindaran Eror Stetement goto merupakan konstruksi pemrograman yg secara bawaan rentan thd eror

Pemrograman terstruktur berarti :

pemrograman tanpa penggunaan statement goto

Hanya menggunakan loop while dan statement if sebagai konstruksi kontrol

Pemrog terstruktur mrpk batu loncatan yg penting bagi pengembangan RPLPenyembunyian Informasi Komponen2program harus diperbolehkan akses hanya ke data yg mereka butuhkan untuk implementasi.

Peyembunyian informasi akan mengakibatkan inf yg disembunyikan tidak dapat dirusak oleh komponen2 program yg tidak seharusnya menggunakannya.Toleransi Kesalahan Tujuannya utk menjamin bahwa kesalahan sistem tidak mengakibatkan kegagalan sistem

Diperlukan pada situasi dimana kegagalan sistem dapat menyebabkan kecelakaan hebat

Atau kerugian operasi sistem akan menyebabkan kerugian ekonomi yg besar

Bebas kesalahan tidak berarti bebas kegagalanAspek toleransi kesalahan :

1. Deteksi kesalahan

2. Penilaian kerusakan

3. Pemulihan kerusakan( status aman

4. Perbaikan kesalahanVALIDASI SISTEM KRITIS Proses V&V harus mendemonstrasikan bahwa sistem memenuhi spesifikasinya dan bahwa layanan dan prilaku sistem mendukung persyaratan klien

Shg diperlukan penambahan analisis dan pengujian normal, karena :

Biaya kegagalan ( jauh lebih besar dr pd sistem non-kritis

Validasi atribut tingkat dependabilitas ( meyakinkan user

Lebih dari 50% biaya pengembangan total utk sistem PL kritis ( agar kegagalan sistem yg mahal terhindari

Contoh : kegagalan sistem PL dalam hal misi pada roket Ariane 5 th 1996, yg mengakibatkan beberapa satelit rusak.

Kualitas sistem dipengaruhi oleh kualitas proses yg dipakai untuk mengembangkan sistem.Validasi System KritisValidasi terhadap reliability (keandalan), safety (keselamatan) dan security (keamanan) bagi sistem berbasis komputerValidation perspectives Validasi Reliability/keandalan Apakah keandalan sistem telah sesuai dengan spesifikasinya?

Apakah keandalan sistem telah memberikan kepuasan pada user pemakai sistem? Validasi Safety/keselamatan Menjamin bahwa kecelakaan tidak akan terjadi atau bahwa konsekuensi kecelakaan akan minimal. Validasi Security/keamanan Apakah sistem dan datanya aman terhadap serangan external?

Tekhnik Validasi Static techniques

Review terhadap disain /inspeksi program

Dynamic techniques

Pengujian Statistik Pengujian berbasis skenario Pemeriksaan Run-time

Process validation

Desain proses pembangunan yang meminimalkan kemungkinan kesalahan dari proses sesuai dgn dependibilitas sistem (keandalan, ketersediaan, keselamatan dan keamanan)Static validation techniques Static validation lebih fokus pada analisa dokumentasi sistem(persyaratan, disain, kode dan data uji) Fokus pada penemuan eror sistem dan identifikasi permasalahan yg berpotensi muncul saat exekusi.

Beberapa dokumen (argumen terstruktur, pembuktian secara matematis, dll) dapat disiapkan utk mendukung validasi statikStatic techniques for safety validation Menunjukkan keselamatan sistem melalui sebuah pengujian merupakan sesuatu yg sulit

Karena pengujian bertujuan utk menunjukkan apa yg dilakukan sistem saat situasi normal. Tidak mungkin dilakukan pengujian thd setiap kondisi operasionalSafety reviews1. Peninjauan thd Review for kebenaran function

2. Peninjauan thd maintainable, understandable structure

3. Peninjauan thd algorithma dan disain struktur data berdasarkan spesifikasi4. Peninjauan thd konsistensi kode dgn algorithma dan disain struktur data5. Peninjauan thd kelayakan sistem pengujianReview guidance1. Buatlah software sesederhana mungkin2. Gunakan teknik yg sederhana dlm pencegahan error seperti menghindari pemakaian pointers and recursion

3. Gunakan information hiding (penyembunyian inf) agar inf yg dsembunyikan tidak dirusak oleh komponen program yg tidak seharusnya menggunakannya4. Gunakan teknik toleransi kesalahan yg sesuai , namun jangan pernah berfikir bahwa hasilnya benar-benar amanHazard-driven analysis1. Efektif atau tidaknya jaminan keselamatan bergantung pada identifikasi bahaya

2. Keselamatan dapat dijamin melaluia. Menghindari bahaya( sistem pemotongan yg menuntut operator agar menekan 2 tombol terpisahb. Deteksi dan membuang bahaya( deteksi tekanan berlebihan dan pembukaan katup sebelum meledak pd pabrik kimiac. Membatasi kerusakan ( pemadam api otomatis3. Safety review (ulasan keselamatan) harus menunjukkan bahwa satu atau lebih teknik ini telah diterapkan untuk semua bahaya yg telah diidentifikasi

The system safety case1. Saat ini praktek formal untuk keselamatan menjadi hal yang diperlukan untuk keselamatan semua sistem berbasis komputer, misalnya isyarat rel kereta api, pengendalian lalu lintas udara, dan lain-lain

2. Kasus keselamatan menyajikan daftar argumen, berdasarkan bahaya yg teridentifikasi3. Mengapa ada penerimaan yg rendah thd kemungkinan bahwa bahaya ini tidak akan mengakibatkan kecelakaan

4. Argumen dapat didasarkan pada bukti formal, desain dasar, keselamatan bukti, dll. Faktor Proses mungkin juga dimasukkanFormal methods and critical systems Pengembangan sistem kritis adalah salah satu 'keberhasilan' dari metode formal Di Inggris digunakan untuk pengembangan beberapa jenis perangkat lunak keamanan untuk aplikasi pertahanan Saat ini tidak ada perjanjian umum tentang nilai metode formal dalam pengembangan sistem

Formal methods and validation Specification validation

Developing a formal model of a system requirements specification forces a detailed analysis of that specification and this usually reveals errors and omissions

Mathematical analysis of the formal specification is possible and this also discovers specification problems

Formal verification

Mathematical arguments (at varying degrees of rigour) are used to demonstrate that a program or a design is consistent with its formal specification

Formal methods conclusion1. Spesifikasi formal dan memeriksa komponen sistem yang penting adalah sangat berguna

a. Walaupun formalitas tidak memberikan jaminan, hal ini membantu untuk meningkatkan keyakinan dalam sistem dgn mendemonstrasikan bahwa beberapa kesalahan tidak muncul2. Verifikasi formal hanya mungkin digunakan untuk sistem yg sangat kecil, kritis, dan utk komponen sistem

a. Kurang lebih 5-6000 baris kode

Safety proofs1. Safety proofs are intended to show that the system cannot reach in unsafe state

2. Weaker than correctness proofs which must show that the system code conforms to its specification

3. Generally based on proof by contradiction

a. Assume that an unsafe state can be reached

b. Show that this is contradicted by the program code

4. May be displayed graphicallyConstruction of a safety proof Establish the safe exit conditions for a component or a program

Starting from the END of the code, work backwards until you have identified all paths that lead to the exit of the code

Assume that the exit condition is false

Show that, for each path leading to the exit that the assignments made in that path contradict the assumption of an unsafe exit from the component Gas warning system System to warn of poisonous gas. Consists of a sensor, a controller and an alarm

Two levels of gas are hazardous

Warning level - no immediate danger but take action to reduce level

Evacuate level - immediate danger. Evacuate the area

The controller takes air samples, computes the gas level and then decides whether or not the alarm should be activated

Gas sensor controlGas_level: GL_TYPE ; loop

-- Take 100 samples of air

Gas_level := 0.000 ;

for i in 1..100 loop

Gas_level := Gas_level + Gas_sensor.Read ;

end loop ;

Gas_level := Gas_level / 100 ;

if Gas_level > Warning and Gas_level < Danger then

Alarm := Warning ; Wait_for_reset ;

elsif Gas_level > Danger then

Alarm := Evacuate ; Wait_for_reset ;

else

Alarm := off ;

end if ;end loop ;

Key points Safety-related systems should be developed to be as simple as possible using safe development techniques

Safety assurance may depend on trusted development processes and specific development techniques such as the use of formal methods and safety proofs

Safety proofs are easier than proofs of consistency or correctness. They must demonstrate that the system cannot reach an unsafe state. Usually proofs by contradiction

Dynamic validation techniques These are techniques that are concerned with validating the system in execution

Testing techniques - analysing the system outside of its operational environment

Run-time checking - checking during execution that the system is operating within a dependability envelope

Reliability validation Reliability validation involves exercising the program to assess whether or not it has reached the required level of reliability

Cannot be included as part of a normal defect testing process because data for defect testing is (usually) atypical of actual usage data

Statistical testing must be used where a statistically significant data sample based on simulated usage is used to assess the reliabilityStatistical testing Testing software for reliability rather than fault detection

Measuring the number of errors allows the reliability of the software to be predicted. Note that, for statistical reasons, more errors than are allowed for in the reliability specification must be induced

An acceptable level of reliability should be specified and the software tested and amended until that level of reliability is reached

Reliability validation process Establish the operational profile for the system

Construct test data reflecting the operational profile

Test the system and observe the number of failures and the times of these failures

Compute the reliability after a statistically significant number of failures have been observed

Operational profiles An operational profile is a set of test data whose frequency matches the actual frequency of these inputs from normal usage of the system. A close match with actual usage is necessary otherwise the measured reliability will not be reflected in the actual usage of the system

Can be generated from real data collected from an existing system or (more often) depends on assumptions made about the pattern of usage of a system

Operational profile generation Should be generated automatically whenever possible

Automatic profile generation is difficult for interactive systems

May be straightforward for normal inputs but it is difficult to predict unlikely inputs and to create test data for themReliability modelling A reliability growth model is a mathematical model of the system reliability change as it is tested and faults are removed

Used as a means of reliability prediction by extrapolating from current data

Simplifies test planning and customer negotiations

Depends on the use of statistical testing to measure the reliability of a system version

Observed reliability growth Simple equal-step model but does not reflect reality

Reliability does not necessarily increase with change as the change can introduce new faults

The rate of reliability growth tends to slow down with time as frequently occurring faults are discovered and removed from the software

A random-growth model may be more accurate

Growth model selection Many different reliability growth models have been proposed

No universally applicable growth model

Reliability should be measured and observed data should be fitted to several models

Best-fit model should be used for reliability prediction

Reliability validation problems1. Operational profile uncertainty

a. Is the operational profile an accurate reflection of the real use of the system

2. High costs of test data generation

a. Very expensive to generate and check the large number of test cases that are required

3. Statistical uncertainty for high-reliability systems

a. It may be impossible to generate enough failures to draw statistically valid conclusions

Security validation1. Security validation has something in common with safety validation

2. It is intended to demonstrate that the system cannot enter some state (an unsafe or an insecure state) rather than to demonstrate that the system can do something

3. However, there are differences

a. Safety problems are accidental; security problems are deliberate

b. Security problems are more generic; Safety problems are related to the application domain

Security validationExperience-based validation

The system is reviewed and analysed against the types of attack that are known to the validation team

Tool-based validation

Various security tools such as password checkers are used to analyse the system in operation

Tiger teams

A team is established whose goal is to breach the security of the system by simulating attacks on the system.

Key points Statistical testing supplements the defect testing process and is intended to measure the reliability of a system

Reliability validation relies on exercising the system using an operational profile - a simulated input set which matches the actual usage of the system

Reliability growth modelling is concerned with modelling how the reliability of a software system improves as it is tested and faults are removed

The portable insulin pumpValidating the safety of the insulin pump system

Safety validation Design validation

Checking the design to ensure that hazards do not arise or that they can be handled without causing an accident.

Code validation

Testing the system to check the conformance of the code to its specification and to check that the code is a true implementation of the design.

Run-time validation

Designing safety checks while the system is in operation to ensure that it does not reach an unsafe state.

Insulin system hazards insulin overdose or underdose (biological)

power failure (electrical)

machine interferes electrically with other medical equipment such as a heart pacemaker (electrical)

parts of machine break off in patients body(physical)

infection caused by introduction of machine (biol.)

allergic reaction to the materials or insulin used in the machine (biol).

Safety proofs Safety proofs are intended to show that the system cannot reach in unsafe state

Weaker than correctness proofs which must show that the system code conforms to its specification

Generally based on proof by contradiction

Assume that an unsafe state can be reached

Show that this is contradicted by the program code

Insulin delivery system1. Safe state is a shutdown state where no insulin is delivered

a. If hazard arises,shutting down the system will prevent an accident

2. Software may be included to detect and prevent hazards such as power failure

3. Consider only hazards arising from software failure

a. Arithmetic error The insulin dose is computed incorrectly because of some failure of the computer arithmetic

b. Algorithmic error The dose computation algorithm is incorrect

Arithmetic errors Use language exception handling mechanisms to trap errors as they arise

Use explicit error checks for all errors which are identified

Avoid error-prone arithmetic operations (multiply and divide). Replace with add and subtract

Never use floating-point numbers

Shut down system if exception detected (safe state)

Algorithmic errors Harder to detect than arithmetic errors. System should always err on the side of safety

Use reasonableness checks for the dose delivered based on previous dose and rate of dose change

Set maximum delivery level in any specified time period

If computed dose is very high, medical intervention may be necessary anyway because the patient may be illInsulin delivery code// The insulin dose to be delivered is a function of blood sugar level, the previous dose // delivered and the time of delivery of the previous dose

currentDose = computeInsulin () ;

// Safety check - adjust currentDose if necessary

if (previousDose == 0)

// if statement 1

{

if (currentDose > 16)

currentDose = 16 ;

}

else

if (currentDose > (previousDose * 2) )

currentDose = previousDose * 2 ;

if ( currentDose < minimumDose )

// if statement 2

currentDose = 0 ;

// then branch

else if ( currentDose > maxDose )

// else branch

currentDose = maxDose ;

administerInsulin (currentDose) ;

System testing System testing of the software has to rely on simulators for the sensor and the insulin delivery components.

Test for normal operation using an operational profile. Can be constructed using data gathered from existing diabetics

Testing has to include situations where rate of change of glucose is very fast and very slow

Test for exceptions using the simulator

Safety assertions Predicates included in the program indicating conditions which should hold at that point

May be based on pre-computed limits e.g. number of insulin pump increments in maximum dose

Used in formal program inspections or may be pre-processed into safety checks that are executed when the system is in operation

Safety assertions static void administerInsulin ( ) throws SafetyException

{

int maxIncrements = InsulinPump.maxDose / 8 ;

int increments = InsulinPump.currentDose / 8 ;

// assert currentDose InsulinPump.maxDose)

throw new SafetyException (Pump.doseHigh);

else

for (int i=1; i maxIncrements)

throw new SafetyException ( Pump.incorrectIncrements);

} // for loop

} //administerInsulin