OSCR 3

Projektowanie OSCR

Grzegorz Granosik

Oprogramowanie systemów czasu rzeczywistego

2

Cechy dobrego oprogramowania

Dobre oprogramowanie

Bezpieczne (safe)

Pewne (reliable)

Poprawne (correct)

Statycznie zgodne ze
specyfikacją.

Czy i jak dobrze
program realizuje swoje
zadanie gdy zostanie
uruchomiony.

Wymaganie odnosi się do
konsekwencji nieprawidłowego
działania: zranienie, śmierć, straty
materialne.

Może się zdarzyć, że poprawne oprogramowanie nie jest
pewne: zostanie sprawdzone zgodnie ze specyfikacją ale w
układzie nie spełnia swojego zadanie – bo specyfikacja była zła.
Lub odwrotnie: program realizuje zamkniętą pętlę regulacji,
powinien generować sterowanie z określoną dokładnością jeśli
tego nie robi jest niepoprawny ale dla małych błędów układ
zamknięty może działać pewnie.

System może działać 100% pewnie
ale być niebezpieczny.
I odwrotnie możemy napisać
niepewny program ale będzie w 100%
bezpieczny… jeśli go nie włączymy

Oprogramowanie systemów czasu rzeczywistego

3

Skutki błędu systemu

Odpowiedź na błąd

Stop

Działa dalej (fault tolerant)

Utrzymuje pełne usługi
(fail operational)
Systemy krytyczne gdzie
zatrzymanie miałoby
skutki katastrofalne

Zredukowane usługi (fail
active)
Np. system awaryjnego
dojazdu ze zmniejszoną
prędkością

Fail hard
Systemy, których zatrzymanie
nie powoduje żadnych szkód,
a występowanie błędu i tak
prowadzi do niemożliwości
pracy i stopu (np.. PC)

Fail Safe
Ograniczamy zniszczenia przez
zatrzymanie (np. reaktor
jądrowy)

Oprogramowanie systemów czasu rzeczywistego

4

Software errors

– dowolna cecha programu, która powoduje

jego nieprawidłowe działanie

Błędy oprogramowania

Efekty środowiskowe

Projekt programu

Projekt systemu

Struktura kodu

Oprogramowanie systemów czasu rzeczywistego

5

Projekt systemu

„

Faza wstępna (najważniejsza)

„

Dobra specyfikacja założeń – jeśli zrobimy
złe założenia dotyczące działania systemu i
środowiska, możemy mieć poważne kłopoty
w fazie realizacji i odbioru

„

Rada dla programistów – przygotuj
elastyczne oprogramowanie, nigdy nie
wiadomo gdzie i ile razy trzeba je będzie
zmieniać

Oprogramowanie systemów czasu rzeczywistego

6

Projekt programu, kodowanie

„

Błędy związane są z błędnym myśleniem o
problemie lub jego rozwiązaniu (nie mają
związku z fizycznym układem)

Logiczne

Znaczeniowe

(semantyczne)

Składniowe (syntax)

Algorytmiczne

Oprogramowanie systemów czasu rzeczywistego

7

Błędy składniowe (syntax)

„

Definicja i układ symboli tworzących program – słowa
kluczowe, zmienne, delimitery

„

Użycie złego symbolu np. „:” zamiast „;” – zazwyczaj
łatwo wykrywane przez kompilatory

„

Złe użycie symbolu:

‰

If (x=y) run();

‰

If (x==y) run();

„

Najlepiej używać języków wysokiego poziomu – im mniej
piszemy tym mniejsza szansa na popełnienie błedu

Oprogramowanie systemów czasu rzeczywistego

8

Błędy znaczeniowe (semantyczne)

„

Niedokładnie zrozumieliśmy co
oprogramowanie ma tak naprawdę rozbić i
zrobiliśmy coś innego (ale poprawnie)

„

Nieprawidłowo zakodowaliśmy to co
oprogramowanie ma robić – złe zrozumienie
lub znajomość języka programowania

Oprogramowanie systemów czasu rzeczywistego

9

Błędy logiczne

„

Ten typ błędów powoduje, że program nie
zachowuję się w sposób logiczny:

‰

przebieg programu jest poprawny ale wyniki
nieprawidłowe, potencjalne przyczyny:

„

Post-check zamiast pre-check,

„

brak zerowania (inicjacji) zmiennych),

„

sprawdzanie złego warunku

‰

może się zawieszać, potencjalne przyczyny:

„

Nieskończone pętle,

„

Zakleszczenie w programach wielowątkowych (deadlock)

Oprogramowanie systemów czasu rzeczywistego

10

Błędy algorytmiczne

„

Pojawiają się w operacjach matematycznych:

„

Overflow, za krótki typ zmiennej, zła znajomość
reprezentacji liczb na danej maszynie (największa liczba
jaką maszyna może przechować, najmniejsza liczba,
relacja pomiędzy największym i najmniejszym
argumentem jednej operacji, precyzja)

„

Dzielenie przez 0 – niezdeterminowany wynik

„

Zakres wejść-wyjść

„

Jednostki przyjęte w obliczeniach (ich spójność)

Oprogramowanie systemów czasu rzeczywistego

11

Efekty środowiskowe

„

Oprogramowanie systemów RT nie może być

traktowane jako samodzielna całość – jest

częścią większego procesu obejmującego nie

tylko hardware ale i ludzi

„

Jak oprogramowanie zachowuje się w

otoczeniu, w którym ma docelowo działać –

pewne problemy ujawniają się dopiero

podczas uruchomienia całego systemu

„

Potrzeba głębokiej i całościowej analizy

procesu w fazie projektu systemu

Oprogramowanie systemów czasu rzeczywistego

12

Skąd się bierze złe oprogramowanie

„

Jest niepoprawne

„

Jest niepewne

„

Jest niebezpieczne

„

Nie jest dostarczone na czas

„

Jest zbyt drogie

Specyficzne problemy

implementacyjne

Możliwości zespołu

Zła organizacja firmy

Oprogramowanie systemów czasu rzeczywistego

13

Etos firmy

„

Złe zarządzanie – brak lub niechęć
zrozumienia potrzeb zespołów programistów,
developerów oprogramowania

„

Brak dyscypliny związanej z projektem
i dokumentacją

„

Złe narzędzia

„

Brak profesjonalizmu

Oprogramowanie systemów czasu rzeczywistego

14

Możliwości merytoryczne zespołu

„

Dobre oprogramowanie nigdy nie powstaje

przez przypadek

„

Niedocenianie skomplikowania zadania

„

Niedostateczna dokumentacja

„

Niewystarczające korzystanie z narzędzi

programistycznych

„

Brak prototypowania systemu

„

Tworzenie projektów od podstaw – brak

ponownego użycia softwaru (biblioteki

pakiety)

Oprogramowanie systemów czasu rzeczywistego

15

Specyficzne problemy implementacyjne

„

Niejasne wymagania (specyfikacja projektu) –

wszyscy wiedzą co system ma robić ale nic nie jest

spisane

„

Przekroczenie czasu i/lub budżetu

„

Źle dostarczone oprogramowanie

„

Brak lub słaba dokumentacja

„

Równoczesne tworzenie hardwaru i softwaru

„

Złe wykorzystanie zasobów

„

Użyteczność i granice testów,

„

Użycie klienta docelowego jako rozszerzenia okresu

testowego

Oprogramowanie systemów czasu rzeczywistego

16

Tworzenie dobrego oprogramowania -
podstawy

„

Jasno określone wymagania

„

Sprawdzenie, że zaproponowane rozwiązanie spełni wymagania:

‰

Dostępny czas

‰

Dokładność i poprawność danych wejściowych

‰

Wymagana dokładność obliczeń

‰

Interfejs użytkownika

‰

Parametry zasilania

‰

Wymagania specjalne dot. działania np. podtrzymanie bateryjne

‰

Specjalne wymagania dot. środowiska działania np. radiacja

‰

Czy użyto właściwego języka programowania

‰

Czy jest wsparcie (narzędzia programistyczne, dokumentacja)

‰

Czy wystarczające zasoby systemowe

‰

Czy będą dotrzymane wymagania czasowe programu, a co jeśli

w testach wyjdzie, że nie? A co ze zdarzeniami

asynchronicznymi i sporadycznymi?

Oprogramowanie systemów czasu rzeczywistego

17

Tworzenie dobrego oprogramowania -
podstawy

„

Organizacja projektu aby był łatwy do zarządzania

‰

Modularyzacja

‰

Zadania końcowe są dostatecznie małe – dla jednej osoby

‰

Struktura równoległych (konkurencyjnych) działań

„

Organizacja projektu aby możliwe było utrzymanie terminów

„

Uniwersalność programu aby mógł być łatwo modyfikowany

‰

Portability – przenośność między platformami, procesorami,

konfiguracjami, kompilatorami

‰

Reusability – komponenty programowe: niezależna cześć

większego systemu, wykonująca określoną funkcję, posiadająca

jasno określone interfejsy. Przykładowe kryteria podziału

komponentów:

„

Aplikacja ogólnego przeznaczenia – aplikacja specjalistyczna

„

Kod źródłowy – linkowalna biblioteka (binarna lub program w FPGA)

„

Niezależny od dostawcy – specyficzny dla dostawcy

Oprogramowanie systemów czasu rzeczywistego

18

Tworzenie dobrego oprogramowania -
podstawy

„

Testowalność i łatwość serwisowania

‰

Program musi być zrozumiały i jednoznaczny (nie tylko dla twórcy!)

‰

Możliwość łatwego i szybkiego przewidzenia skutków określonych

modyfikacji programu jest niezwykle pożądana

‰

Unikanie programowania ryzykownego

‰

Unikanie trików programowych

‰

Unikanie konstrukcji programowych działających tylko lokalnie,

specyficznych dla maszyny lub aplikacji

„

Minimalizacja ryzyka przez użycie znanych i sprawdzonych

metod

‰

Programowanie obiektowe zapewnia dobre środowisko

developerskie, standardowe i sformalizowane podejście,

standardowe dokumentowanie

„

Zapewnienie właściwego priorytetu dla bezpieczeństwa

„

Unikanie sytuacji, gdy projekt zależy od konkretnych osób

Oprogramowanie systemów czasu rzeczywistego

19

Unikanie błędów, programowanie
defensywne

„

Zakładamy, że błędy są nieuniknione – staramy się ograniczyć

skutki ich pojawienia się – musimy poznać ich naturę i źródła:

‰

Human factor (zmiana parametrów systemu na zgubne dla niego)

‰

Błędy obliczeniowe (dzielenie przez 0, przekroczenie zakresów

zmiennych)

‰

Awaria sprzętu (niepojawienie się sygnału z zewnątrz)

„

Zapobiegać możliwości wprowadzenia błędu (ograniczyć

dopuszczalne zmiany parametrów)

„

Wykryć błąd jeśli się pojawi (i wprowadzić system w safe mode –

exception handling)

„

Monitorować zachowanie systemu (i odpowiadać na awarię

szybko, bezpiecznie i deterministycznie)

Oprogramowanie systemów czasu rzeczywistego

20

Cykl tworzenia oprogramowania

Problem klienta

Analiza problemu

Specyfikacja wymagań

Projekt architektury

Projekt fizyczny

Implementacja

Debug i testy

Uruchominie systemu

Wymagania klienta

Struktura programu

Struktura hard/soft

Moduły programowe

Pakiet programów

Wymagania systemu

Wymagania programu

Oprogramowanie systemów czasu rzeczywistego

21

Źródło i koszt błędów

Żródła błędów

Koszt znalezienia i usunięcia

Specyfikacja w ymagań

Projekt systemu

Kod programu

Inne

Oprogramowanie systemów czasu rzeczywistego

22

Źródła
specyfikacji

Problem formułowania specyfikacji

Informacja jawna

Informacja ukryta

Wiedza

Trade-off

Formułowanie

problemu

Niespójność

Założenia

Brak informacji

Problemy

Obszar wiedzy klienta

Obszar
wiedzy
projektanta

Kanały wymiany
informacji

Techniki

Mowa

Diagramy i modele

Tekst

Problemy

Niejednoznaczność

Złożoność

Sprzeczność

Niezrozumiałość

Oprogramowanie systemów czasu rzeczywistego

23

Specyfikacja wymagań

Interfejsy

Osiągi

Funkcja

Co ma robić

Ograniczenia

Software world interface

Real world interface

Jak dobrze ma

robić

Jak

komunikuje się

z otoczeniem

Co wolno a co nie

wolno robić

Databases

Operating

systems

Plant

Man-machine

Oprogramowanie systemów czasu rzeczywistego

24

Specyfikacja wymagań czasowych

Czynnik

ludzki

Obliczenia

numeryczne

Pętle

sterujące

Czasy

odpowiedzi

Możliwości

obliczeniowe

Oprogramowanie systemów czasu rzeczywistego

25

Dokumentacja

„

Definiuje:

‰

Co, dlaczego i na kiedy klient chce

‰

Jak i kiedy projektant rozwiąże problem

‰

Szczegóły systemu, osiągi, użytkowanie

„

Informuje

‰

Optymalne jest połączenie tekstu i diagramów

„

Rejestruje przebieg projektu

‰

Założenia

‰

Deliverables

‰

Stan faktyczny produktu

‰

Cechy i osiągi produktu

‰

Instalacja, obsługa, testy

‰

Historia modyfikacji

Oprogramowanie systemów czasu rzeczywistego

26

Dokumentacja a etapy projektu

Projekt

systemu

Specyfikacja

wymagań

Implementacja

Integracja,

debug, testy

Specyfikacja

oczekiwanych

funkcji

Specyfikacja

hardware i

software

Kody

programu

Dokumentacja

testów

Opis aplikacji

Opis instalacji

systemu

Oprogramowanie systemów czasu rzeczywistego

27

Case study

„

Tepson