Validasi System Kritis - Adekyanna's Blog | Modul Kuliah · Web viewSistem hrs bekerja andal dan...

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 mobil

PL 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 kesalahan”

Ada beberapa alasan lain mengapa sistem PL yg dapat diandalkan belum tentu menjamin keselamatan

1. Spesifikasi mungkin tidak lengkapTingkat persentase malfungsi sistem yg tinggi merupakan akibat dari eror spesifikasi, bukan eror perancangan.

1. Malfungsi perangkat kerasShg menyebabkan PL menghasilkan suatu lingkungan yg tidak dapat

diantisipasi3. Operator sistem

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

1. Menghindari bahaya2. 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 kerusakanDgn menyertakan fitur proteksi yg akan meminimalisasi kerusakancth : pemadam api otomatis, sebelum melukai penumpang dan awak pesawat

KEAMANAN• 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 tersedia2. Korupsi program atau data

– Karena perubahan komponen PL3. Penyingkapan informasi rahasia4. Keamanan semakin penting dgn beragamnya sistem yg terhubung dgn internet5. 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 sebenarnya

Spesifikasi 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 terjadi

Analisa 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 teknologi

PENGEMBANGAN 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 kesalahan

Persyaratan utk pengembangan PL yg bebas dr kesalahan :1. Harus ada spesifikasi sistem yg tepat2. Organisasi yg mengembangkan sistem hrs memiliki kultur kualitas organisasi3. Hrs digunakan pendekatan perancangan dan implementasi PL yg berdasarkan

penyembunyian informasi dan enkapsulasi4. Gunakan bhs pemrograman yg strongly-typed (dpt mendeteksi kesalahan lebih

banyak oleh kompilator)5. Menghindari penulisan yg potensial rentan thd eror6. Proses pengembangan hrs didefenisikan. Manajer kualitas hrs memeriksa

kesesuaian proses

Penghindaran 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 RPL

Penyembunyian 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 kegagalan

Aspek toleransi kesalahan :1. Deteksi kesalahan2. Penilaian kerusakan3. Pemulihan kerusakanà status aman

4. Perbaikan kesalahan

VALIDASI 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 Kritis

Validasi terhadap reliability (keandalan), safety (keselamatan) dan security (keamanan) bagi sistem berbasis komputer

Validation perspectives Validasi Reliability/keandalan

o Apakah keandalan sistem telah sesuai dengan spesifikasinya?o Apakah keandalan sistem telah memberikan kepuasan pada user

pemakai sistem? Validasi Safety/keselamatan

o Menjamin bahwa kecelakaan tidak akan terjadi atau bahwa konsekuensi kecelakaan akan minimal.

Validasi Security/keamanano Apakah sistem dan datanya aman terhadap serangan external?

Tekhnik Validasi Static techniques

o Review terhadap disain /inspeksi program Dynamic techniques

o Pengujian Statistiko Pengujian berbasis skenarioo Pemeriksaan Run-time

Process validationo 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 statik

Static 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 operasional

Safety reviews1. Peninjauan thd Review for kebenaran function2. Peninjauan thd maintainable, understandable structure3. Peninjauan thd algorithma dan disain struktur data berdasarkan

spesifikasi

4. Peninjauan thd konsistensi kode dgn algorithma dan disain struktur data

5. Peninjauan thd kelayakan sistem pengujian

Review guidance1. Buatlah software sesederhana mungkin2. Gunakan teknik yg sederhana dlm pencegahan error seperti

menghindari pemakaian pointers and recursion3. Gunakan information hiding (penyembunyian inf) agar inf yg

dsembunyikan tidak dirusak oleh komponen program yg tidak seharusnya menggunakannya

4. Gunakan teknik toleransi kesalahan yg sesuai , namun jangan pernah berfikir bahwa hasilnya benar-benar aman

Hazard-driven analysis1. Efektif atau tidaknya jaminan keselamatan bergantung pada

identifikasi bahaya2. Keselamatan dapat dijamin melalui

a. Menghindari bahayaà sistem pemotongan yg menuntut operator agar menekan 2 tombol terpisah

b. Deteksi dan membuang bahayaà deteksi tekanan berlebihan dan pembukaan katup sebelum meledak pd pabrik kimia

c. 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 teridentifikasi

3. 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 dimasukkan

Formal 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

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

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

Formal verificationo 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 bergunaa. Walaupun formalitas tidak memberikan jaminan, hal ini membantu

untuk meningkatkan keyakinan dalam sistem dgn mendemonstrasikan bahwa beberapa kesalahan tidak muncul

2. 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 state2. Weaker than correctness proofs which must show that the system code

conforms to its specification3. Generally based on proof by contradiction

a. Assume that an unsafe state can be reachedb. Show that this is contradicted by the program code

4. May be displayed graphically

Construction 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

o Warning level - no immediate danger but take action to reduce levelo 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 airGas_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 ;

©Ian Sommerville 2000 CS 365 Critical Systems Validation Slide 17

Graphical argument

Gas_level > Warning and Alarm = off Unsafe state

Gas_level > Warning and Gas_level < Danger

Gas_level > Danger

Alarm = WarningAlarm = Evacuate Alarm = off

or or or

contradiction contradiction

Path 1 Path 2 Path 3


Condition checking

Gas_level < Warning Path 3 Alarm = off (Contradiction)Gas_level = Warning Path 3 Alarm = off (Contradiction)Gas_level > Warning andGas_level < Danger

Path 1 Alarm = Warning(Contradiction)

Gas_level = Danger Path 3 Alarm = offGas_level > Danger Path 2 Alarm = Evacuate

(Contradiction)

Code is incorrect. Gas_level = Danger does not cause the alarm to be on

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 techniquesl 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 reliability

Statistical 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


An operational profile

Numberof inputs

Inputclasses

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 them

Reliability 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

o Simplifies test planning and customer negotiations Depends on the use of statistical testing to measure the reliability of a system

version


Equal-step reliability growth

t1 t2 t3 t4 t5

Reliability(ROCOF)

Time

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


Random-step reliability growth

t1 t2 t3 t4 t5Time

Note differentreliabilityimprovements Fault repair adds new fault

and decreases reliability(increases ROCOF)

Reliability(ROCOF)

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 prediction

Reliability

Requiredreliability

Fitted reliabilitymodel curve

Estimatedtime of reliability

achievement

Time

= Measured reliability

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 generationa. Very expensive to generate and check the large number of test cases

that are required3. 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 validation2. 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 differencesa. Safety problems are accidental; security problems are deliberateb. 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 validationVarious security tools such as password checkers are used to analyse the system in operation

Tiger teamsA 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

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

Code validationo 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 validationo 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 patient’s body(physical) infection caused by introduction of machine (biol.) allergic reaction to the materials or insulin used in the machine

(biol).


Fault tree for software hazards

Incorrectsugar levelmeasured

Incorrectinsulin doseadministered

or

Correct dosedelivered atwrong time

Sensorfailure

or

Sugarcomputation

error

Timerfailure

Pump signalsincorrect

or

Insulincomputation

incorrect

Deliverysystemfailure

Arithmeticerror

or

Algorithmerror

Arithmeticerror

or

Algorithmerror

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

o Assume that an unsafe state can be reachedo 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 accident2. Software may be included to detect and prevent hazards such as power failure3. 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 ill

Insulin 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 necessaryif (previousDose == 0) // if statement 1{

if (currentDose > 16)currentDose = 16 ;

}else

if (currentDose > (previousDose * 2) )currentDose = previousDose * 2 ;

if ( currentDose < minimumDose ) // if statement 2currentDose = 0 ; // then branch

else if ( currentDose > maxDose ) // else branchcurrentDose = maxDose ;

administerInsulin (currentDose) ;


Informal safety proof

Insulin_dose = 0

Insulin_dose := 0

if statement 2then partexecuted

Insulin_dose =Maximum_dose

Insulin_dose :=Maximum_dose

if statement 2elsif partexecuted

if statement 2not executed

Insulin_dose >= Minimum_dose andInsulin_dose <= Maximum_dose

or

Insulin_dose >Maximum_dose

Administerinsulin

Contradiction

Contradiction Contradiction

Pre-conditionfor unsafe state

Overdoseadministered

See Portrait slide

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.maxDoseif (InsulinPump.currentDose > InsulinPump.maxDose)

throw new SafetyException (Pump.doseHigh);else

for (int i=1; i<= increments; i++){

generateSignal () ;if (i > maxIncrements)

throw new SafetyException ( Pump.incorrectIncrements);

} // for loop} //administerInsulin

Validasi System Kritis - Adekyanna's Blog | Modul Kuliah · Web viewSistem hrs bekerja andal dan...

Documents

Transcript of Validasi System Kritis - Adekyanna's Blog | Modul Kuliah · Web viewSistem hrs bekerja andal dan...