Wprowadzenie do analizy wymagań systemów czasu rzeczywistego (SCR)

Skomputeryzowany system czasu rzeczywistego obejmuje:

• zbiór komponentów sprzętowych: mikroprocesory, pamięć, sterowniki programowalne
• zbiór komponentów programowych realizujących automatyczne przetwarzanie danych

SCR jest sprzężony z otoczeniem. Jego zadaniem zbieranie danych pochodzących z procesu zachodzącego w otaczającym go środowisku oraz reagowanie na nie z opóźnieniem ustalanym przez dynamikę procesu zachodzącego w otoczeniu. Opóźnienie to może mieć wartość rzędu od kilku mikrosekund do kilku milisekund.

Interfejs pomiędzy systemem i środowiskiem

Sprzęt i oprogramowanie wchodzące w skład SCR są bardzo silnie sprzężone. Oba te komponenty realizują wymianę z otoczeniem.

Wymieniane dane mają charakter ciągły lub dyskretny.

Dane ciągłe w czasie mają wartość zdefiniowaną w każdym momencie czasu. Odpowiadają one wartościom fizycznym (temperatura, prędkość, siła). W SCR dane te muszą zostać przetworzone do wartości dyskretnych przez próbkowanie i konwersję A/D. Dane ciągłe mogą mieć nieskończony lub skończony zbiór wartości. Przykładem skończonego zbioru jest zmienna binarna - np.: przycisk monostabliny zwolniony i naciśnięty.

Dane dyskretne w czasie mają skończony zbiór wartości. Są one zdefiniowane w wybranych momentach czasu. Przykładem mogą być sygnały sterujące (nastawy), komendy wysyłane do sterowników cyfrowych (w postaci łańcuchów ASCII), dane przesyłane do wyświetlacza.

Przerwania mają charakter specjalny - nie przenoszą żadnych wartości. Istotne jest ich pojawienie się. Rozróżnialne wartości to ich obecność lub brak obecności.

Bodźce przesyłane z otoczenia do SCR może mieć formę:

• przerwania
• pojawienia się danej dyskretnej
• zmiany wartości danej ciągłej

Akcje wykonane przez SCR na środowisku w odpowiedzi na bodźce polegać mogą na:

• wysłaniu przerwania
• wysłaniu danych dyskretnych
• zmianie wartości danych ciągłych

Wydajność czasowa SCR

Wymiany danych pomiędzy otoczeniem i systemem odbywają się przy ograniczeniach czasowych. Wydajność systemów może dotyczyć:

• czasu odpowiedzi systemu (Czas odpowiedzi jest to maksymalny czas pomiędzy detekcją sygnału zewnętrznego i odpowiadającą mu akcją)
• szybkości transmisji danych (prędkość zbierania lub generacji danych)

Stany SCR

W każdym momencie czasu SCR znajduje się w pewnym trybie działania, który determinuje jego obserwowalne zachowanie. Nazywany jest on stanem bieżącym.

Liczba stanów SCR jest skończona (w odróżnieniu od systemów analogowych).

Z punktu widzenia logiki sterowania systemy można podzielić na:

• kombinatoryczne - informacja na wyjściu jest całkowicie zdeterminowana przez informacje na wejściu
• sekwencyjne - informacja na wyjściu zależy od kombinacji informacji wejściowych i bieżącego stanu systemu

SCR są z natury sekwencyjne

Cykl życia SCR

Najogólniejszy podział etapów życia (tworzenia i eksploatacji) SCR jest następujący:

1. sformułowanie wymagań, które system ma spełniać
2. jego rozwój
3. jego eksploatacja i konserwacja

Sformułowanie wymagań

Etap ten obejmuje działania, które zapoczątkowują i mają największy wpływ na proces tworzenia systemu:

• identyfikacja wymagań
• studium realizowalności systemu, który powinien je spełniać

Identyfikacja wymagań jest prowadzona w formie dialogu pomiędzy przyszłym użytkownikiem (właścicielem) i realizatorem.

Jej zadaniem jest:

1. zdefiniowanie koncepcji działania systemu
2. analiza alternatyw
3. sformułowanie wymagań funkcjonalnych i wyznaczenie potencjalnych wymagań
4. określenie ograniczeń dotyczących zużycia zasobów
5. ustalenie wymagań dotyczących jakości

Studium realizowalności obejmuje:

• aspekty techniczne,
• aspekty ekonomiczne, spełnienie norm oraz aspekty prawne, które związane są z tworzeniem systemu
• czynnik ludzki

Studium realizowalności może posunąć się do stworzenia wstępnego prototypu systemu.

W ramach studium realizowalności analizowane są: aspekty techniczne, funkcje, wydajność i ograniczenia w celu określenia:

• ryzyka związanego z rozwojem
• dostępności zasobów ludzkich
• dostępności sprzętu i innych zasobów technicznych

Dla SCR badanie realizowalności ma na celu przede wszystkim oszacowanie czasów przetwarzania, czasów odpowiedzi, prędkości transmisji danych oraz zużycia zasobów.

Rezultat powyższych analiz po dołączeniu informacji dotyczących kosztów, źródeł zaopatrzenia w sprzęt i oprogramowanie, wymagań jakościowych formułowany jest w postaci dokumentu.

Zapis wymagań oraz studium realizowalności stanowi punkt wyjścia dla dalszego rozwoju systemu.

Fazy rozwoju systemu (cykl rozwoju systemu)

Fazy te obejmują:

• specyfikację wymagań
• projekt
• konstrukcję (implementację)
• integrację
• walidację (testowanie)

Specyfikacja wymagań jest to opis techniczny wymagań, które system ma spełnić. Jest to zapis częściowo formalny, który pozwala opisać otoczenie i zachowanie systemu bez brania pod uwagę założeń technicznych (informatycznych). Specyfikacja wymagań powinna dawać odpowiedź na pytanie: co system ma robić.

Faza projektowania ma na celu zaproponowaniu architektury systemu oraz architektury jego komponentów a także ustalenie zasad konstrukcji systemu. Projekt powinien odpowiedzieć na pytanie: jak wykonać system.

Zazwyczaj faza projektowania dzielona jest na dwa etapy:

1. projekt wstępny (określenie globalnej architektury systemu i sposobu integracji jego głównych komponentów)
2. projekt szczegółowy obejmujący sposób budowy jego komponentów (programowych i sprzętowych)

Przejście pomiędzy fazą specyfikacji i projektowania wymaga:

1. przydziału funkcji i wymagań dotyczących wydajności do komponentów sprzętowych i programowych
2. specyfikacji sprzętu i oprogramowania

Konstrukcja systemu obejmuje:

• dla oprogramowania: implementację (kodowanie), testy modułów i integrację oprogramowania
• dla sprzętu: stworzenie prototypu testy i pomiary

Integracja systemu polega na scalaniu elementów oprogramowania i sprzętu w docelowym otoczeniu.

Walidacja systemu polega na sprawdzeniu, czy jest on zgodny z wymaganiami sformułowanymi przez użytkownika (właściciela).

Model wodospadowy

Model kontroli jakości

specyfikacja wymagań						walidacja
	projekt wstępny				integracja
		projekt szczegółowy		testy
			konstrukcja

Podstawy specyfikacji SCR

Modelowanie

Specyfikacja jest procesem, w którym tworzony jest abstrakcyjny opis systemu. Zadaniem jej jest znalezienie reprezentacji podstawowych własności i aspektów działania systemu pozbawionej szczegółów technicznych.

Proces redukcji, a następnie rozszerzania opisu systemu nosi nazwę modelowania, w wynikowa reprezentacja nazywana jest modelem.

Pomocnym narzędziem jest hierarchizacja opisów. Zadaniem hierarchizacji jest zarządzanie złożonością opisów. Tworzenie specyfikacji ma charakter procesu wieloetapowego:

• system dzielony jest na podsystemy,
• podsystemy dzielone są na elementy prostsze

Zbiór wszystkich tych opisów, w połączeniu z interfejsami obejmuje system w całej jego złożoności.

Model logiczny i fizyczny

Model logiczny rozumiany jest jako opis tego, co system ma robić; model fizyczny jako specyfikacja, w jaki sposób ma to zostać zrealizowane.

Model fizyczny obejmuje aspekt technologiczny jego realizacji, a także osoby, obiekty fizyczne, dokumenty.

Model logiczny obejmuje:

• opis funkcjonalny (funkcje systemu)
• opis informacyjny (przetwarzane dane)
• opis zdarzeniowy.

Opisy funkcjonalny i informacyjny są wspólne dla wszystkich systemów informatycznych.

Opis zdarzeniowy jest charakterystyczny dla SCR, które muszą reagować na sygnały pochodzące z otoczenia i realizować transformacje danych w zależności od stanu elementów sterujących.

Przedmiotem zainteresowania będzie aspekt technologiczny modelu fizycznego (oprogramowanie).

Metody specyfikacji

Diagramy przepływów danych (DFD)

SART Ward-Mellor

SART Hatley-Pirbhai

Diagramy ERD

Opis funkcjonalny

Opis funkcjonalny SCR obejmuje funkcje, które system powinien pełnić oraz informacje, które powinien przetwarzać bez bezpośrednich odwołań do uwarunkowań technologicznych.

Obejmuje on:

1. dane, które są przetwarzane, ich źródła, ich adresaci i miejsca ich tymczasowego magazynowania
2. transformacje, którym podlegają dane pomiędzy ich pojawieniem się na wejściu i generacją na wyjściu

Analiza strukturalna proponuje formalne narzędzie modelowania, które pozwala na

• reprezentację operacji, które wykonuje system podczas transformowania danych
• specyfikację procesów, które transformują dane

Przykład

Diagram kontekstowy Błąd! Nieznany argument przełącznika.:

• precyzuje co jest zadaniem systemu poprzez określenie jego podstawowej funkcji użytkowej
• określa granicę, która oddziela go od otoczenia, z którym jest zintegrowany.

Granica jest wyznaczona przez elementy należące do otoczenia, z którymi system wymienia dane. Stanowią one brzeg modelu.

Rys. 1Diagram kontekstowy

Diagram wstępny (Błąd! Nieznany argument przełącznika.) pokazuje pierwszy poziom dekompozycji podstawowej funkcji użytkowej systemu.

System dzielony jest na procesy, pomiędzy którymi krążą przepływy danych. Mogą one docierać bezpośrednio (polecenie_wydruku ) lub być magazynowane (surowe pomiary, typ pomiarów).

Rys. 2 Diagram wstępny

Każdy z procesów ma funkcję podstawową: ODSEPARUJ surowe pomiary, SPORZĄDŹ raport, WIZUALIZUJ krzywą.

Procesy te mogą zostać dalej zdekomponowane. Błąd! Nieznany argument przełącznika. i Błąd! Nieznany argument przełącznika. pokazują dekompozycję procesów 6.0 i 7.0

Rys. 3 Dekompozycja procesu 6.0

Rys. 4 Dekompozycja procesu 7.0

Diagramy DFD

Poprzedni przykład pokazuje cztery elementy występujące w DFD: przepływy danych, procesy, magazyny danych i elementy terminalne

Elementy składowe DFD

Przepływ danych

Definicja Przepływ danych pokazuje drogę, po której dane przemieszczają się pomiędzy miejscami transformacji. Może zawierać dane proste (pierwotne) lub złożone (np.: informacje o pomiarach zawierają daną składową czas pomiarów) Każda z danych może być interpretowana jako informacja, materia lub energia.

Reprezentacja Strzałka etykietowana identyfikatorem danych. Identyfikator danych powinien mieć formę rzeczownika z przymiotnikami i nie powinien implikować w żaden sposób przetwarzania.

• formularz rejestracji użytkownika jest właściwą nazwą przepływu danych
• wyświetlanie formularza jest błędną nazwą

Proces

Definicja Proces jest elementem działania realizowanym przez system. Proces transformuje co najmniej jedne przepływ danych wejściowych w co najmniej jeden przepływ danych wyjściowych. Proces konsumuje, przetwarza, składuje i produkuje przepływy danych.

Reprezentacja Okrąg otaczający identyfikator procesu i numer referencyjny. Identyfikator procesu powinien opisywać wykonywaną transformację używając czasownika (w trybie rozkazującym lub bezokoliczniku) z dopełnieniem określającymi typ przetwarzanych.

Numer referencyjny identyfikuje miejsce danego procesu w hierarchii powstałej w wyniku dekompozycji.

Magazyn danych

Definicja magazyn danych reprezentuje daną prostą lub zgrupowanie danych, które jest stale dostępne dla wszystkich procesów danego poziomu i niższego. Zawartość magazynu może zostać zmodyfikowana jedynie przez proces dokonujący zapisu.

Reprezentacja Dwie linie równoległe otaczające identyfikator. Zasady nazewnictwa analogiczne, jak dla przepływów danych.

Elementy terminalne (granice modelu)

Definicja Element terminalny reprezentuje obiekt umieszczony w otoczeniu systemu, który stanowi źródło lub jest adresatem przepływów danych wymienianych pomiędzy systemem i jego zewnętrznym środowiskiem. Może opisywać urządzenie peryferyjne, czujnik, siłownik, osobę lub inny system.

Reprezentacja Prostokąt otaczający identyfikator. Nazwa elementu powinna odzwierciedlać rolę, jaką pełni on w systemie.

Składnia DFD

Dopuszczalne połączenia

	proces	magazyn	symbol terminalny
proces	wymagana nazwa	domyślnie przyjmowana jest nazwa magazynu	wymagana nazwa
magazyn	domyślnie przyjmowana jest nazwa magazynu
symbol terminalny	wymagana nazwa

Uproszczenia w reprezentacji

Uproszczenia w reprezentacji dotyczą magazynów i przepływów danych.

1. Nazwa przepływu docierającego do magazynu danych może zostać pominięta, jeśli jest identyczna z nazwą magazynu.
2. Dostęp do magazynu procesu, który pisze i czyta mogą symbolizować strzałki umieszczone na obu końcach symbolu przepływu.
3. Jeżeli przepływ danych reprezentuje zgrupowanie danych - uproszczenia dotyczą rozgałęzień i połączeń.

1. Poprawa czytelności

Dopuszczalne jest powtórzenie na schemacie symbolu magazynu lub symbolu terminalnego po dodaniu gwiazdki do identyfikatora.

Reguły interpretacji DFD

Reguły interpretacji DFD ustalają domyślną semantykę modelu.

Reguła aktywacji. Warunkiem wkw. aktywacji procesu jest obecność wszystkich danych wejściowych. W wyniku aktywacji procesu pojawiają się dane wyjściowe.

Reguła konsumpcji. Dane przenoszone przez przepływ danych są konsumowane przez proces je wykorzystujący (w kolejności nadejścia) i następnie znikają po użyciu. Magazyny danych przechowują dane w sposób trwały. Po odczycie są dostępne do odczytu dla dalszych procesów. Magazyny pozostają niezmienione aż do następnego zapisu.

Brak jest szczególnych założeń dotyczących wartości początkowych magazynów.

W niektórych zastosowaniach jest to konwencja niewygodna. Czasem rozróżnia się magazyny nie wyczerpywane i wyczerpywane (np.: kolejki FIFO).

Standardowo jednak magazyny należy interpretować jak dzielony plik w problemie czytelników i pisarzy.

Reguła zachowania Jedynie te przepływy opuszczają proces, które można stworzyć na podstawie przepływów wejściowych. (Np. polecenie wizualizacji albo polecenie wydruku).

Reguła konieczności Proces akceptuje tylko te przepływy wejściowe, które są niezbędne do wytworzenia przepływów wyjściowych. (Tu tylko podzbiór danych element)

Reguła autonomii Proces akceptuje dane wejściowe i produkuje dane wyjściowe bez rozróżnienia ich pochodzenia i przeznaczenia.

Hierarchizacja modelu funkcjonalnego

Diagram kontekstowy reprezentuje szczyt hierarchii. Składa się wyłącznie z jednego procesu, którego nazwa odzwierciedla podstawową funkcję systemu.

Jest to jedyny diagram, na którym pojawiają się elementy terminalne reprezentujące interfejsy pomiędzy systemem i otoczeniem.

Warstwy dekompozycji Diagram pierwszego poziomu nazywany jest diagramem wstępnym. Pokazuje on dekompozycję systemu na podsystemy, które odpowiadają podstawowym funkcjom systemu oraz na ich interfejsy.

Każdy podsystem jest z kolei traktowany jako system i dalej iteracyjnie dekomponowany na podsystemy.

Przy przejściu pomiędzy poziomami następuje dekompozycja procesu wyższego poziomu na podprocesy. Rezultat dekompozycji zapisany jest w formie diagramu DFD. Proces dekomponowany nazywany jest rodzicem, diagram DFD - diagramem potomnym.

Dekompozycji procesu towarzyszy odpowiednia transformacja kontekstu - czyli przepływów danych, które proces czyta lub tworzy. Grupy danych mogą być dekomponowane na podgrupy lub dane pierwotne.

Każdy poziom diagramu DFD nosi nazwę i numer referencyjny procesu rodzica. Każdy proces posiada numer, którego przedrostkiem jest numer rodzica, natomiast przyrostkiem numer procesu na diagramie. (Reguła ta nie stosuje się do diagramu pierwszego poziomu.)

Abstrakcja i maskowanie informacji

DFD danego poziomu zawiera jedynie te informacje (procesy, magazyny i przepływy), które są niezbędne do zapewnienia pełnej reprezentacji, lecz bez zbędnych szczegółów.

Przepływy danych i magazyny istniejące wewnątrz dekomponowanego procesu są niewidoczne na wyższej warstwie. Są one maskowane na danym poziomie i odkrywane przy przejściu do niższego poziomu.

Rys. 5Diagram procesu 3.0

Rys. 6 Dekompozycja procesu 3.1

Przejście pomiędzy poziomami powoduje, że diagram potomny zawiera dokładnie te same przepływy wejściowe i wyjściowe, które miał proces rodzicielski.

Zachowanie przepływów danych jest ustalane na podstawie użycie tych samych nazw (identyfikatorów).

Podczas hierarchizacji wprowadza się dodatkowe reguły syntaktyczne dotyczące przepływów danych. Może nastąpić rozbijanie danych podczas przejścia pomiędzy poziomami. Rys. 7 Dekompozycja danej A na B oraz C

[+magazyn]

Specyfikacja procesów

Rezultatem dekompozycji jest osiągnięcie poziomu, gdzie dalsza dekompozycja nie jest już prowadzona. Pojawiające się tam procesy nazywane są procesami prymitywnymi (pierwotnymi).

Wymagają one odrębnej specyfikacji - stąd najniższy poziom dekompozycji nosi nazwę warstwy specyfikacji procesów.

Specyfikacja procesów wymaga opisu w jaki sposób tworzona jest informacja wyjściowa na podstawie informacji wejściowej. Opis ten powinien obejmować wszystkie wejścia, nie zawierać niejednoznaczności i wskazań implementacji.

Specyfikacja procesów wykorzystuje przepływy i magazyny danych. Wszystkie dane powinny być zawarte w słowniku danych.

Istnieje kilka sposobów specyfikacji procesów:

• specyfikacja proceduralna
• przez podanie prewarunków i postwarunków

Specyfikacja proceduralna podaje w opisowy sposób algorytm, który jest używany do wytworzenia danych wyjściowych.

Polega ona na:

• Stworzeniu tekstu, w którym używany jest pewien podzbiór języka naturalnego. Zazwyczaj używane są czasowniki w bezokoliczniku lub trybie rozkazującym typu: utworzyć, składować, zapisać, znaleźć, wybrać, zwrócić. Opisują one operacje wykonywane na danych pochodzących z kontekstu specyfikowanego procesu.
• Organizacji tekstu za pomocą pseudoinstrukcji wysokiego poziomu (sekwencji, iteracji, alternatywy).

Przykład specyfikacji procesu

Proces POBIERZ dane eksperymentu Wydaj komende zaladowania pliku odpowiadającego nazwie eksperymentu IF wskaznik obecności ma wartość TRUE THEN przypisz rezultatowi wartość SUKCES zapisz plik pomiarów jako dane eksperymentu ELSE przypisz rezultatowi wartość PORAŻKA ENDIF zwróć rezultat.

Specyfikacja za pomocą prewarunków i postwarunków

Specyfikacja ta pokazuje relacje przyczynowe pomiędzy przepływami wejściowymi i wyjściowymi, opisuje warunki konieczne powstania danych na wyjściu, bez wchodzenia w szczegóły przetwarzania

Przykład specyfikacji:

PRE	nazwa eksperymentu jest wprowadzona
POST	komenda zaladowania jest wydana
PRE	wskaznik obecności ma wartość TRUE AND nazwa eksperymentu jest wprowadzona
POST	rezultat ma wartość SUKCES AND dane eksperymentu zawiera plik pomiarów
PRE	wskaznik obecności ma wartość FALSE
POST	rezultat ma wartość PORAŻKA

Inne rodzaje specyfikacji

Specyfikacja tabelaryczna pokazuje w tabeli zależności pomiędzy wartościami danych na wejściu i wyjściu

wejścia		wyjścia
typ głowicy wiertniczej	prędkość natarcia	stan funkcjonowania	energia poczatkowa
7.5 J	0.9 1.1	dobry	0.5
7.5 J	1.1 0.9	zły	nie określona
15 J	1.9 2.1	dobry	4
15 J	2.1 1.9	zły	nie określona

• Możliwa jest specyfikacja za pomocą wzorów matematycznych

• Możliwa jest też specyfikacja opisowa (bardziej lub mniej dokładna)

IN: e (błąd), k (współczynnik wzmocnienia)

OUT: y (sterowanie)

OPIS: Proces wyznacza sterowanie y na podstawie wartości błędu e

Opis zdarzeniowy

Opis funkcjonalny koncentruje się na sposobie przetwarzania danych. Opis zdarzeniowy dotyczy:

• warunków określających, kiedy procesy działają - czyli zdarzeń, które je aktywują i deaktywują
• sposobu, w jaki zdarzenia zmieniają zachowanie systemu.

Opis zdarzeniowy jest związany z modelowaniem systemu jako maszyny zawierającą skończoną liczbę stanów. Przyjmuje się, że w danym momencie system znajduje się w jednym ze stanów określających jego przyszłe obserwowalne zachowanie.

Pojawienie się zdarzeń lub pewnych kombinacji zdarzeń wywołuje akcje i generację innych zdarzeń, a tym samym wywołuje zmianę stanu systemu.

Narzędzie modelowania cech zdarzeniowych powinno pozwalać na

1. opis zdarzeń, które mają wpływ na działanie systemu,
2. specyfikację logiki przetwarzania, która prowadzi do generacji zdarzeń wyjściowych w zależności od zdarzeń wejściowych i stanu systemu.

Elementy opisu zdarzeniowego

Zdarzenia

Zdarzenie jest to informacja, która pojawia się w pewnym momencie i oznacza, że "coś się stało". Zdarzenie może być zdarzeniem prostym lub kombinacją zdarzeń prostych.

1. Przykładami zdarzeń prostych są sygnały pochodzące z otoczenia: przerwanie, pojawienie się danej dyskretnej, zmiana wartości danej ciągłej o skończonej liczbie wartości...
2. Inne zdarzenia proste mogą być generowane wewnętrznie podczas transformacji danych, jako rezultat testów pewnych predykatów.

Jeżeli proces transformujący dane wykorzystuje dane ciągłe, wówczas osiągnięcie pewnego progu lub przedziału wartości może powodować generację zdarzenia prostego.

Identyfikator takiego zdarzenia ma zwykle postać "temperatura>100°", "predkosc < 5m/s", "przycisk_wcisniety = true"

W przypadku, kiedy wykorzystywane są dane dyskretne w czasie, źródłem zdarzenia może być pojawienie się danej lub pojawienie się i przyjęcie przez nią jednej z wartości, np.: "wprowadzona_częstotliwość_próbkowania", "kod_poprawny=true".

Decyzja, czy wartość dyskretna w czasie powinna być traktowana jak zdarzenie, czy też jako dana zależy od jej użycia w systemie.

Przykład

1. Dana kod_poprawny może być traktowana jako przepływ danych, który przyjmuje dwie wartości - true i false. Wartości te mogą być używane przez proces transformujący dane w celu obliczania liczby autoryzowanych dostępów i prób wejścia bez autoryzacji.
2. Każda zmiana (ustawienie) wartości zmiennej może być traktowane jako zdarzenie - stąd możemy wyróżnić dwa zdarzenia "kod_poprawny=true" oraz "kod_poprawny=false".

Możliwe jest także inne podejście. Informacja kod_poprawny jest traktowana jako dana, natomiast zmiana (ustawienie) wartości powoduje generację zdarzenia kod_poprawny_zmieniono. W reakcji na to zdarzenie system powinien odczytać nową wartość zmiennej (danej).

Akcje

Zdarzenia mogą wywoływać wewnętrzne akcje, które zmieniają stan procesów transformujących dane. Zasadniczo, akcje te polegają na aktywacji i deaktywacji pewnego procesu.

Rozróżnia się trzy podstawowe typy akcji:

• zezwolenie na działanie, które powoduje aktywację procesu (ang. enable); akcja oznaczana jest przez <E>
• zabronienie działania (ang. disable); akcja oznaczana jest przez <D>
• jednorazowe uruchomienie procesu (ang. trigger); akcja oznaczana jest przez <T>

Czasem rozróżnia się szczególne rodzaje zezwolenia i zabronienia: suspend <S> zawiesza przetwarzanie bez niszczenia tymczasowych rezultatów; resume <R> reaktywuje proces zatrzymany za pomocą suspend.

Jest kwestią umowną, jak traktować poszczególne akcje. Akcja enable może inicjować proces, akcja disable usuwać proces, suspend zawieszać bez usuwania, resume reaktywować bez powtórnej inicjalizacji.

Dobrym przykładem jest OSWIETLENIE - proces transformujący energię elektryczną w energię świetlną:

• Włącznik bistabilny załącza <E>nable lub wyłącza <D>isable oświetlenie
• Włącznik monostabilny (jak na klatkach schodowych) powoduje włączenie oświetlenia na pewnie czas <T>rigger.

W przykładzie bardziej zwiazanym z oprogramowaniem:

• <E> może oznaczać stworzenie zadania lub jego reaktywację
• <D> może oznaczać usunięcie lub zawieszenie zadania
• <T> może oznaczać wywołanie funkcji, wysłanie komunikatu do kolejki wejściowej zadania, wykonanie semGive (operacji V) dla semafora synchronizacyjnego.

Celem modelu logicznego jest abstrahowanie od tego typu szczegółów i pozostawienie pewnej swobody implementacji.

Logika sterowania

Mechanizm prowokowania zdarzeń i akcji na podstawie pewnej kombinacji pojawiających się zdarzeń nazywany jest logiką sterowania.

Logika sekwencyjna. Jeżeli wyjścia logiki sterowania są funkcją bieżącego stanu systemu i bieżących zdarzeń wejściowych - logika ta nazywana jest logiką sekwencyjną. Ponieważ bieżący stan systemu jest rezultatem ostatnich zdarzeń wejściowych, logika sekwencyjna implikuje konieczność istnienia pamięci, która przechowuje pewną ścieżkę działania systemu. Stan systemu odpowiada więc pewnemu wewnętrznemu stanowi pamięci jego logiki sterowania.

Logika kombinatoryczna. Jeśli wyjścia są jedynie funkcją bieżących wejść, wówczas logika sterowania nazywana jest kombinatoryczną i nie musi mieć żadnej pamięci.

Zazwyczaj logika sterowania SCR jest logiką sekwencyjną, ale pewne jego podsystemy mogą zadowalać się logiką kombinatoryczną.

Reprezentacja aspektów zdarzeniowych

Metody Warda-Mellora (WM) i Hatleya-Pirbhai (HP) proponują rozszerzenia do Analizy Strukturalnej uwzględniające aspekt zdarzeniowy.

Rozszerzenia te obejmują:

• Reprezentację graficzną dla przepływów zdarzeń oraz logiki sterowania . Dzięki temu możliwe jest odróżnienie dane od zdarzeń oraz procesy transformujące dane od procesów odpowiedzialnych wyłącznie za sterowanie.
• Hierarchizację opisu zdarzeniowego analogiczną do hierarchizacji opisu funkcjonalnego

Przykład

Diagram (w notacji Warda-Mellora) pokazuje proces, którego zadaniem jest sterowanie amplitudą sygnału dźwiękowego. Ciągły przepływ danych sygnał dźwiękowy przetwarzany jest na sygnał po regulacji.

Regulacja amplitudy uaktywnia się w przypadku przekroczenia progów maksymalnego lub minimalnego.

Specyfikacja logiki sterowania

Logika sekwencyjna

W logice sekwencyjnej reakcja na bodźce zależy od bieżącego stanu sterowania. Opis sterowania prowadzony jest z wykorzystaniem maszyn skończenie stanowych.

Analizując powyższy przykład wyodrębnimy trzy stany pracy:

• NORMALNY (bez regulacji)
• WZMOCN (wzmocnienie sygnału)
• REDUKCJA (redukcja amplitudy sygnału)

oraz

• SPOCZYNEK (spoczynek, bez przetwarzania sygnału)

Definicja maszyny może być podana w postaci tabeli stanów i przejść lub w postaci diagramu.

Specyfikacja tabelaryczna (tabela stanów i przejść)

M={S, I, O, F_S, F_O, s₀) Fs  SIS, Fs  SIO

stan (S)	warunek (I)	akcja (O)	następny stan
SPOCZYNEK	wlacz	<E>czytaj sygnal	NORMALNY
NORMALNY	wylacz	<D> CZYTAJ sygnal	SPOCZYNEK
NORMALNY	ponizej_min	<E>ZWIEKSZ amplitude	WZMOCN
NORMALNY	powyzej_max	<E>ZMNIEJSZ amplitude	REDUKCJA
WZMOCN	wylacz	<D> ZWIEKSZ amplitude <D> czytaj sygnal	SPOCZYNEK
WZMOCN	poziom_normal	<D> ZWIEKSZ amplitude	NORMAL
REDUKCJA	wylacz	<D> ZMNIEJSZ amplitude <D> CZYTAJ sygnal	SPOCZYNEK
REDUKCJA	poziom_normal	<D> ZMNIEJSZ amplitude	NORMAL

Analogiczne zależności opisuje poniższy diagram stanów i przejść

Przejście

Ogólna postać przejścia jest następująca:

• dozór może być kombinacją logiczną zdarzeń prostych;
• akcja może składać się z kilku akcji; domyślnie przyjmuje się, że wykonywane są one równolegle, chyba, że wyspecyfikowana jest kolejność wykonania

Zasady interpretacji

System oczekuje na zdarzenie wejściowe w danym stanie. Po pojawieniu się zdarzenia odpowiadającego dozorowi następuje przejście.

W przypadku pojawienia się zdarzenia, dla którego w danym stanie brak jest dozoru - zdarzenie jest ignorowane.

W przypadku pętli prowadzącej do stanu wyjściowego - system w reakcji na zdarzenie wejściowe wykona akcję, lecz nie będzie ona powodowała zmiany stanu

W przypadku, kiedy zdarzenia wejściowe połączone są operatorem koniunkcji, zakładamy, że powinny mieć one miejsce równocześnie lub system czeka na pojawienie się wszystkich wymaganych zdarzeń.

W przypadku, kiedy zdarzenia wejściowe połączone są operatorem alternatywy - wystarczy jedno z nich, aby dokonać przejścia.

Przykład logiki kombinatorycznej (notacja Hatley-Pirbhai)

Przykład pokazuje automatyczną kasę do sprzedaży biletów.

Obiekt odpowiedzialny za logikę sterowania jest przedstawiony w postaci pionowej pogrubionej linii. Akcje odpowiedzialne za aktywacje lub deaktywację procesów nie są uwidaczniane na diagramie. Umieszcza się je w tabeli aktywacji procesów.

Wiersze tabeli aktywacji procesów pokazują odwzorowanie kombinacji zdarzeń wejściowych w akcje aktywacji procesów, a także w zdarzenia wyjściowe.

• tak - odpowiada pojawieniu się zdarzenia
• nie - odpowiada nieobecności zdarzenia
• prawda - odpowiada przyjęciu wartości prawdy przez ciągłą zmienną binarną
• fałsz - odpowiada zmianie wartości zmiennej na fałsz

zdarzenia wejściowe			transformacje				zdarzenia wyjściowe
potwierdzenie	anulacja	bilet_dostępny	ZWROC monety	INKASUJ monety	DOSTARCZ bilet	ZERUJ opłatę	bilet_dostarczony	monety_zwrócone
tak	tak	X	0	0	0	0	nie	nie
tak	nie	prawda	0	1	1	2	tak	nie
tak	nie	fałsz	1	0	0	1	nie	tak
nie	tak	X	1	0	0	1	nie	tak
nie	nie	X	0	0	0	0	nie	nie

Brak aktywności procesu oznaczony jest przez 0, aktywność przez liczbę dodatnią (1,2...). Liczby opisują kolejność aktywacji procesów.

Opis informacyjny - przetwarzane dane

Uzupełnieniem opisu funkcjonalnego i zdarzeniowego jest opis przetwarzanych danych. W klasycznych programach dane przetwarzane przez system mogą być:

• proste - opisującego pojedynczą wielkość
• złożone - stanowią one zgrupowanie danych typu prostego.

W systemach czasu rzeczywistego uwzględnia się także aspekt czasowy:

• dane mogą być ciągłe lub dyskretne w czasie i reprezentować wielkości fizyczne
• zdarzenia są szczególnym przypadkiem danych dyskretnych

Specyfikacja danych złożonych

W klasycznym podejściu Analizy Strukturalnej (DeMarco) dane definiuje się z wykorzystaniem notacji Backusa-Naura.

Symbol	Znaczenie
=	zdefiniowane jako
+	zgrupowanie (bez określonego porządku)
[|]	albo - wyliczenie możliwych wartości
{}	iteracja bez zakresów
n{}p	iteracja od n do p
n{}	iteracja - co najmniej n
{}p	iteracja od 0 do p
n{}n	iteracja - dokładnie n
" "	ograniczniki literału
* *	komentarz
@	oznacza klucz przy definicjach iteracyjnych

Przykłady:

polecenie	= [polec_wydruku | polec_wizualizacji]
dane eksperymentu	= info o pomiarach + surowe pomiary
surowe pomiary	= 1 {@moment + surowy pomiar } 4096
surowy pomiar	= 12 {@numer_bitu+wartosc_bitu}12
numer_bitu	=[1|2|.....9|10|11|12]
wartosc_bitu	=[1|0]

Specyfikacja danych prostych

Dane pierwotne są scharakteryzowane przez:

• ich typ (binarny, całkowitoliczbowy, rzeczywisty, tekstowy...)
• dziedzinę (przedział, skończony zbiór wartości)
• opcjonalnie - wartość defaultową
• jednostkę (s, Hz, m/s, J)
• precyzję

Przykład:

moment

= * moment czasowy w którym przeprowadzono pomiar * * typ: całkowity, przedział 1-4096, jednostka s *

Słownik danych

Słownik danych zawiera specyfikacje wszystkich przepływów i magazynów, które występują w diagramach DFD oraz specyfikacjach procesów.

Słownik danych pełni rolę bazy danych z nazwami identyfikatorów i ich definicjami. Jego zadaniem jest zapewnienie spójności pomiędzy różnymi poziomami hierarchii opisu funkcjonalnego (i zdarzeniowego).

Spójność dotyczy:

• identyczności przepływów wejściowych i wyjściowych procesu prymitywnego na diagramie DFD i przepływów występujacych w jego specyfikacji
• identyczności przepływów wejściowych i wyjściowych w procesie złożonym i odpowiadającym mu diagramie potomnym

w przypadku rozbicia przepływu danych na części składowe przy przejściu pomiędzy dwoma poziomami hierarchii - opierając się na definicji danych zawartej w słowniku ustala się poprawność tej operacji

Metodologia specyfikacji Warda-Mellora (WM)

W metodologii WM model logiczny nazywany jest modelem podstawowym (ang. essential ) natomiast model fizyczny modelem implementacji.

Model implementacji rozszerza model podstawowy (logiczny) wprowadzając do niego szczgóły techniczne zapewniające implementację systemu dla wybranej technologii sprzętu i oprogramowania. Stanowi więc odwzorowanie modelu logicznego na pewną platformę technologiczną.

Zdarzenia

Metodologia WM odróżnia informacje będące nośnikiem wartości od informacji, które są istotne ze względu na sam fakt ich wystąpienia.

Dane stanowią informacje będące nośnikiem wartości. Dzielą się one na dane:

1. ciągłe w czasie lub będące stale dostępne
2. dane dyskretne w czasie lub dostępne przejściowo

Dana dyskretna w czasie ma dwa elementy składowe: skończony zbiór wartości oraz czas jej pojawienia się.

Dane nie będące nośnikiem wartości są z natury dyskretne. Ich rola w systemie redukuje się do samego faktu wystąpienia (obecności lub nie obecności).

Zdarzenie jest informacją nie przenoszącą wartości. Traktowane jest jak sygnał pochodzący z otoczenia (np.: przerwanie sprzętowe) lub sygnał generowany przez proces transformujący dane (np.: przerwanie programowe).

Zdarzenie ma charakter przejściowy (ulotny). Aby być dostępne w sposób bardziej trwały, powinno być przechowywane w magazynie zdarzeń.

Reprezentacja

Model podstawowy obejmuje opis funkcjonalny wzbogacony o opis zdarzeniowy. Specyfikuje on:

• przepływy danych
• przepływy zdarzeń
• procesy (nazywane transformacjami danych)
• jednostki sterujące (nazywane transformacjami sterowania)

Diagramy modelu podstawowego stanowią rozszerzenie DFD i nazywane są schematami transformacji (ST). Są one również hierarchiczne, podobnie jak DFD.

Model podstawowy zawiera:

• hierarchiczną reprezentację schematów transformacji
• specyfikacje transformacji danych i sterowania
• w niektórych przypadkach reprezentacje danych w formie diagramów ERD
• specyfikacje danych i zdarzeń w słowniku danych
• specyfikację wymagań czasowych

Model podstawowy składa się z dwóch modeli:

• model otoczenia (diagram kontekstowy oraz listę zdarzeń pojawiających się w otoczeniu, na które system powinien reagować)
• model zachowania (modele zawierające opisy funkcjonale zdarzeniowe i informacyjne)

Schematy transformacji

Przepływy danych Wzbogacone są o rozróżnienie pomiędzy danymi ciągłymi i dyskretnymi w czasie

	dane ciągłe
	dane dyskretne

Elementami służacymi opisowi aspektu zdarzeniowego są:

1. przepływy zdarzeń
2. magazyny zdarzeń
3. transformacje sterowania
4. aktywatory (deaktywatory) procesów

Przepływ zdarzeń reprezentuje drogę, po której przesyłane są zdarzenia pomiędzy procesami transformujacymi dane i transformacjami sterowania.

Magazyn zdarzeń reprezentuje obiekt zdolny przechowywać (buforować) zdarzenia. Dzięki temu zdarzenia stają się trwale dostępne dla wszystkich transformacji, które mogą ich potrzebować.

W odróżnieniu od magazynów danych - magazyn zdarzeń może otrzymywać zdarzenia bezpośrednio z otoczenia, bez konieczności buforowania ich przez proces. (W praktyce taki proces będzie jednak występował - w postaci procedury obsługi przerwań.)

Transformacja sterowania reprezentuje jednostkę sterującą (proces sterujący), która wyznacza zdarzenia wyjściowe na podstawie zdarzeń wejściowych. Nie realizuje ona przetwarzania zdarzeń wejściowych w sensie proceduralnym.

Z zasady transformacje sterowania opierają się na logice sekwencyjnej, stąd najczęściej reprezentowane są w postaci diagramów stanów i przejść lub tabel.

Podobnie, jak dla przepływów danych reprezentowana jest w postaci okręgu, w którym umieszczona jest nazwa i numer referencyjny

Nazwa transformacji ma zazwyczaj postać "sterowanie" lub "steruj", "kontroluj", "zarządzaj" z dopełnieniami określającymi sterowany element systemu.

Aktywatory procesów są zdarzeniami, które skierowane są do procesów transformujących dane. Ich zadaniem jest zmiana stanu tych procesów. Oznaczane są przez <E>nable (aktywacja), <D>isable (zawieszenie), <T>rigger (jednorazowe uruchomienie). Są to zawsze zdarzenia generowane przez proces sterujący. Standardowo, nie nadaje się im nazw, lecz specyfikuje rodzaj akcji: <E>,<D> oraz <T>. Domyślnie nazwą zdarzenia jest rodzaj akcji + nazwa jej adresata, np.: <T> ZERUJ predkosc, <E> WPROWADZ predkosc

Zasady tworzenia schematów transformacji

Poniższe reguły tworzenia diagramów w metodyce WM rozszerzają standardową składnię diagramów DFD.

• transformacja sterowania akceptuje oraz może generować wyłącznie przepływy sterowania
• transformacja sterowania może mieć na wejściu akcje pełniące rolę aktywatorów/deaktywatorów (czyli być aktywowana lub zawieszana przez inną transformację sterowania)
• transformacja sterowania może mieć na wyjściu przepływy pełniące rolę aktywatorów/deaktywatorów, których przeznaczeniem jest transformacja danych albo transformacja sterowania
• transformacje danych proste (prymitywne) akceptują jedynie przepływy sterowania oraz aktywatory/deaktywatory; mogą one wytwarzać przepływy danych i zdarzeń
• wszystkie prymitywne transformacje danych ciągłych powinny być jawnie aktywowane lyb deaktywowane
• prosta (prymitywna) transformacja danych może wysyłać sygnały sterujące do środowiska - za pośrednictwem przepływów zdarzeń.

Poniższa tabela opisuje możliwe połączenia

	transformacja danych	transformacja sterowania	magazyn danych	magazyn sterowania	element terminalny
transformacja danych
transformacja sterowania	E/D/T	E/D/T
magazyn danych
magazyn sterowania
element terminalny

Diagram schematów transformacji może nie zawierać transformacji sterowania lub zawierać ich kilka. Pozwala to na rozproszenie sterowania.

Zasady interpretacji schematów transformacji

1. Zasady interpretacji DFD stosują się do transformacji danych i przepływów danych. Różnice mogą dotyczyć zasad aktywacji deaktywacji. W przypadku jawnej specyfikacji aktywatorów (akcji <E>,<D>, <T> ) , to one decydują o uruchamianiu lub zawieszaniu procesu. Jeżeli dla danego procesu transformującego dane aktywatory nie są określone, oznacza to, że stosują się tu standardowe reguły - warunkiem uaktywnienia procesu jest obecność wymaganych danych na jego wejściu.
2. Aktywatory symbolizują relacje przyczynowości pomiędzy transformacjami, nie powinny być one traktowane jak dane (zdarzenia), które powinny być przetwarzane przez transformację docelową.
3. Magazyny zdarzeń są interpretowane jak semafory licznikowe (w przypadku, kiedy wszystkie zdarzenia są jednakowego typu) lub kolejki komunikatów.

Hierarchia w modelu zachowania

Model zachowania obejmuje diagram wstępny i diagramy, na których specyfikowana jest dekompozycja transformacji danych. Dany poziom hierarchii opisywany jest przez schemat transformacji zawierający przepływy danych, zdarzeń, magazyny danych i zdarzeń, transformacje danych i transformacje sterowania.

Transformacje 2.0 i 3.0 przed dekompozycją	Diagram pokazujący dekompozycję transformacji 2.0

Hierarchizacja sterowania pozwala zdekomponować logikę sterowania i przypisać jej elementy kolejnym poziomom schematów transformacji.

Hierarchizacja pociąga za sobą następujące reguły interpretacji:

1. Kiedy transformacja sterowania TS1 za pomocą aktywatorów (E,D,T) kontroluje stan innej transformacji sterownia TS2, natomiast TS2 nie wysyła zdarzeń E/D/T> do TS1, wówczas TS1 traktowana jest jako opis wyższego poziomu w hierarchii sterowania.
2. Wszystkie transformacje, które są kontrolowane przez daną transformację sterownia TS są zawieszane, kiedy TS jest deaktywowana.
3. Transformacja danych może być aktywna tylko wtedy, kiedy wszystkie jej procesy rodzicielskie są aktywne; jeżeli dana transformacja danych jest nieaktywna, wówczas automatycznie nieaktywne są wszystkie jej procesy potomne.

Specyfikacja transformacji danych

W metodzie WM preferowaną formą specyfikacji prymitywnych transformacji danych jest podanie prewarunków i postwarunków. Dopuszczalne jest każda forma specyfikacji, która w jednoznaczny sposób poda odwzorowanie pomiędzy przepływami wejściowymi li wyjściowymi.

Specyfikacja transformacji sterowania

W metodzie WM podstawowym narzędziem opisu logiki sterowania są maszyny skończenie stanowe opisane za pomącą diagramów przejść i stanów.

Opuszczenie danego stanu jest możliwe po otrzymaniu sygnału ( po pojawieniu się zdarzenia). Podczas przejścia emitowane są zdarzenia wyjściowe - mogą być nimi także akcje aktywujące procesy E/D/T.

Dekompozycja sterowania

Schematy transformacji pociągają za sobą dekompozycję sterowania:

• hierarchiczną (w danym stanie logiki sterowania wyższego poziomu możemy wyróżnić podstany i przejścia pomiędzy nimi)

• na tym samym poziomie

Spójność modelu podstawowego

Wymaganie spójności modelu obejmuje zgodność następujących elementów:

• zachowanie przepływów danych i zdarzeń na wejściu i wyjściu transformacji danych nie prymitywnej oraz jej potomnego schematu transformacji
• przepływy danych na wejściu i wyjściu prymitywnej transformacji danych powinny być zgodne z przepływami występującymi w jej specyfikacji
• przepływy zdarzeń, które składają się dozory na diagramie stanów i przejść powinny być wejściowymi przepływami zdarzeń dla transformacji sterowania
• akcje na diagramie stanów i przejść powinny zawierać zdarzenia wyjściowe lub aktywatory i deaktywatory
• wszystkie aktywacje/deaktywacje transformacji danych powinny być wuspecyfikowane graficznie na odpowiednim diagramie
• wszystkie dane i zdarzenia powinny być wyspecyfikowane w słowniku danych

Przykład

Poniższy przykład pokazuje elementy specyfikacji WM dla prostego systemu sterującego odblokowaniem drzwi za pośrednictwem karty magnetycznej. Podobne systemy można napotkać w przedsiębiorstwach (karta identyfikuje pracowników posiadających prawo wejści do danej strefy) lub w całodobowych bankomatach umieszczonych wewnątrz budynków (karta bankowa umożliwia dostęp do bankomatu poza godzinami funkcjonowania placówki).

Elementami terminalnymi systemu są:

• ręczny czytnik karty (użytkownik przesuwa kartę z pewną prędkością, w trakcie przesuwu odczytywany jest zapis ze ścieżki magnetycznej)
• rygiel bramki (podanie napięcia odblokowuje bramkę, zwolnienie blokuje rygiel)

W zależności od prędkości przesuwu czytnik dobiera prędkość taktowania zegara, który jest używany do dekodowania zapisu na ścieżce magnetycznej.

Dla prędkości przesuwu karty V zawartej w przedziale [10 cm/s - 150 cm/s] oraz założonej gęstości zapisu 75bpi (2.95 bit/mm) )okres zegara wynosi 3.4 ms - 226 s

T = 0.34/V

Diagram kontekstowy

Przepływy danych

• karta_obecna ma charakter przepływu ciągłego. Wykrycie zbocza opadającego oznacza pojawnienie się zdarzenia początek karty
• impulsy - przepływ ciągły. Wartości bitów ustalane będą na podstawie taktowania zegara.
• komenda_otwarcia - przepływ ciągły. Podanie napięcia na okreśony czas odblokuje bramkę

Diagram wstępny

Uwaga - przykład jest tak dobrany, aby schemat transformacji diagramu wstępnego nie podlegał dalszej dekompozycji.

Specyfikacje transformacji danych

2.0 TESTUJ obecnosc karty

PRE	wykryte opadające zbocze sygnału karta obecna
POST	wyślij sygnał początek karty
PRE	wykryte wznoszące zbocze sygnału karta obecna
POST	wyślij sygnał koniec karty

3.0 CZYTAJ ramkę

PRE	brak
POST	bity są umieszczone w magazynie ramka

4.0 SPRAWDZ kod

PRE	ramka zawiera znacznik konca AND kod karty nie jest pusty AND kod karty należy do bazy kodów
POST	wyślij sygnał kod_ok
PRE	ramka zawiera znacznik konca AND kod karty nie jest pusty AND kod karty NIE należy do bazy kodów
POST	wyślij sygnał kod_err
PRE	ramka zawiera znacznik konca AND kod karty jest pusty
POST	wyślij sygnał kod_err

5.0 ODBLOKUJ bramkę

PRE	brak
POST	wyślij komendę otwarcia

6.0 OGRANICZ czas odblokowania

PRE	lokalny czas = opoznienie bramki
POST	wyślij czas uplynal

7.0 ZERUJ ramkę

PRE	brak
POST	ramka jest pusta

Specyfikacje transformacji sterowania

Jedynie proces 1.0 wymaga specyfikacji w postaci diagramu stanów i przejść.

Przejście początkowe uruchamia proces ZERUJ ramkę oraz TESTUJ obecność karty. Zauważmy, że z diagramu wynika, że transformacja TESTUJ obecność karty nigdy nie kończy działania.

Słownik danych

Wymagania czasowe