Microsoft PowerPoint

OSCR 3

Projektowanie OSCR

Grzegorz Granosik

Oprogramowanie systemów czasu rzeczywistego

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ź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

Ź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

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

Specyfikacja wymagań czasowych

Czynnik

ludzki

Obliczenia

numeryczne

Pętle

sterujące

Czasy

odpowiedzi

Możliwości

obliczeniowe

Oprogramowanie systemów czasu rzeczywistego

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

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