Automatyczna weryfikacja wymagań TZ w procesie modelowania dynamicznego

Kontynuując temat „Jakie są twoje dowody?”, spojrzymy na problem modelowania matematycznego z innej strony. Po upewnieniu się, że model odpowiada surowej prawdzie życia, można odpowiedzieć na zasadnicze pytanie: „co tak naprawdę mamy?”. Tworząc model obiektu technicznego, zazwyczaj chcemy się upewnić, że ten obiekt spełni nasze oczekiwania. W tym celu przeprowadza się dynamiczne obliczenia procesów, a wyniki porównuje się z wymaganiami. To jest cyfrowy bliźniak, wirtualny prototyp i inne modne gadżety, które na etapie projektowania rozwiązują problem, jak sprawić, abyśmy otrzymali to, co planowaliśmy.

Jak szybko upewnić się, że nasz system to dokładnie to, co projektujemy, czy poleci, czy popłynie nasza konstrukcja? A jeśli poleci, to jak wysoko? A jeśli popłynie, to jak głęboko?

W artykule rozważana jest automatyzacja weryfikacji spełniania wymagań technicznych budynku przy tworzeniu dynamicznych modeli systemów technicznych. Jako przykład przyjrzyjmy się elementowi specyfikacji technicznej dla systemu chłodzenia powietrzem statku powietrznego.

Rozważamy takie wymagania, które można wyrazić liczbowo i zweryfikować matematycznie na podstawie konkretnego modelu obliczeniowego. Oczywiście to tylko część ogólnych wymagań dla każdego systemu technicznego, ale dokładnie na ich weryfikację poświęcamy czas, nerwy i pieniądze na tworzenie dynamicznych modeli obiektu.

Przy opisie wymagań technicznych w formie dokumentu można wyróżnić kilka rodzajów różnych wymagań, z których każde wymaga różnych podejść do automatycznej weryfikacji ich spełnienia.

Na przykład, rozważmy taki mały, ale rzeczywisty zbiór wymagań:

1. Temperatura atmosferycznego powietrza na wejściu do SVO:
   na postoju − od minus 35 do 35 ºC,
   w locie − od minus 35 do 39 ºC.
2. Statyczne ciśnienie atmosferycznego powietrza w locie − od 700 do 1013 hPa (od 526 do 760 mm rt. st.).
3. Całkowite ciśnienie powietrza na wejściu do wlotu SVO w locie − od 754 do 1200 hPa (od 566 do 1050 mm rt. st.).
4. Temperatura powietrza chłodzącego:
   na postoju − nie więcej niż 27 ºC, dla bloków technicznych − nie więcej niż 29 ºC,
   w locie − nie więcej niż 25 ºC, dla bloków technicznych − nie więcej niż 27 ºC.
5. Zużycie powietrza chłodzącego:
   na postoju − nie mniej niż 708 kg/h,
   w locie − nie mniej niż 660 kg/h.
6. Temperatura powietrza w przedziałach przyrządów − nie więcej niż 60 ºC.
7. Ilość drobno rozpylonej swobodnej wilgoci w powietrzu chłodzącym − nie więcej niż 2 g/kg suchego powietrza.

Nawet w tak ograniczonym zestawie wymagań można wyróżnić co najmniej dwie kategorie, które należy różnie przetwarzać w systemie:

• wymagania dotyczące warunków eksploatacji systemu (pkt 1-3);
• wymagania parametryczne systemu (pkt 3-7).

Wymagania dotyczące warunków eksploatacji systemu
Zewnętrzne warunki dla opracowanego systemu podczas modelowania mogą być określane jako warunki brzegowe lub jako wynik działania ogólnego systemu.
Podczas dynamicznego modelowania należy upewnić się, że określone tryby pracy są pokrywane przez proces modelowania.

Wymagania parametryczne systemu
Te wymagania stanowią parametry zapewniane przez sam system. W trakcie modelowania możemy uzyskać te parametry jako wyniki obliczeń i upewnić się, że wymagania są spełnione w każdym konkretnym obliczeniu.

Identyfikacja i kodowanie wymagań

Dla wygody pracy z wymaganiami istniejące standardy zalecają przypisywanie identyfikatora każdemu wymaganiu. Przy przypisywaniu identyfikatorów bardzo pożądane jest użycie jednolitego systemu kodowania.

Kod wymagania może być po prostu numerem, który odzwierciedla porządkowy numer wymagania, lub może zawierać kod typu wymagania, kod systemu lub agregatu, do którego jest stosowany, kod parametru, kod lokalizacji i wiele innych, co może sobie wyobrazić inżynier. (przykład użycia kodowania zobacz w artykule)

W tabeli 1 przedstawiono prosty przykład kodowania wymagań.

1. kod źródła wymagań R - wymagania TŻ;
2. kod typu wymagań E – wymagania – parametry zewnętrznego środowiska, lub warunki eksploatacji
   S – wymagania zapewniane przez system;
3. kod stanu samolotu 0 – dowolny, G – na postoju, F – w locie;
4. kod typu parametrów fizycznych T – temperatura, P – ciśnienie, G – przepływ, wilgotność H;
5. numer porządkowy wymagania.

Projekt systemu weryfikacji wymagań.

Dla każdego obliczeniowego wymagania istnieje algorytm oceny zgodności obliczonych parametrów z wymaganymi w specyfikacji. Generalnie każda system zarządzania zawsze zawiera w sobie algorytmy weryfikacji wymagań po prostu z definicji. Nawet każdy regulator je zawiera. Gdy temperatura przekracza określone granice, włączany jest klimatyzator. W ten sposób pierwszy etap każdego nadzoru to weryfikacja zgodności parametrów z wymaganiem.

A skoro weryfikacja to algorytm, można wykorzystać te same narzędzia i instrumenty, które używamy do tworzenia programów zarządzania. Na przykład środowisko SimInTech umożliwia tworzenie pakietów projektowych, które zawierają różne części modelu, wykonane jako osobne projekty (model obiektu, model systemu zarządzania, model środowiska itd.).

Projekt weryfikacji wymagań w tym przypadku staje się takim samym projektem algorytmów i łączy się z pakietem modelu. A w trybie modelowania dynamicznego przeprowadza analizę zgodności wymagań z TZ.

Możliwy przykład prezentacji projektu systemu został przedstawiony na rysunku 1.

Rysunek 1. Przykład prezentacji projektu weryfikacji.

Podobnie jak do algorytmów sterowania, wymagania można zorganizować w formie zestawu dokumentów. Dla ułatwienia pracy z algorytmami w środowiskach modelowania strukturalnego, takich jak SimInTech, Simulink, AmeSim, wykorzystuje się możliwości tworzenia struktur wielopoziomowych w postaci submodeli. Taka organizacja pozwala grupować różne wymagania w zestawy, co upraszcza pracę z masywem wymagań, jak w przypadku algorytmów sterowania (zob. rys. 2).

Rysunek 2. Hierarchiczna struktura modelu weryfikacji wymagań.

Na przykład, w rozważanym przypadku wyróżniono dwie grupy: wymagania dotyczące otoczenia oraz wymagania bezpośrednio związane z systemem. Dlatego wykorzystuje się dwupoziomową strukturę danych: dwie grupy, z których każda jest listą algorytmu.

Do podłączenia danych do modelu używana jest standardowa schemat tworzenia bazy danych sygnałów, w której przechowywane są dane do wymiany między częściami projektu.

Podczas tworzenia i testowania oprogramowania do tej bazy umieszczane są odczyty czujników (odpowiadających rzeczywistym czujnikom systemu), które są wykorzystywane przez system sterowania.
W kontekście projektu testowania w tej samej bazie danych mogą być przechowywane dowolne parametry obliczane w dynamicznym modelu, a tym samym wykorzystywane do weryfikacji spełnienia wymagań.

Sam dynamiczny model w tym przypadku może być realizowany w dowolnym systemie modelowania matematycznego lub nawet w formie programu wykonywalnego. Jedynym wymaganiem jest występowanie interfejsów programowych do przekazywania danych o modelowaniu do zewnętrznego środowiska.

Rysunek 3. Podłączenie projektu weryfikacji do złożonego modelu.

Przykład podstawowego arkusza weryfikacji wymagań przedstawiono na rysunku 4. Z punktu widzenia programisty, jest to zwykły schemat obliczeniowy, na którym w formie graficznej przedstawiono algorytm weryfikacji wymagań.

Rysunek 4. Arkusz weryfikacji wymagań.

Główne części arkusza weryfikacji opisano na rysunku 5. Algorytm weryfikacji formułuje się analogicznie do schematów obliczeniowych algorytmów sterowania. W prawej części znajduje się blok odczytu sygnałów z bazy danych. W tym bloku następuje odwołanie do bazy danych sygnałów podczas modelowania.

Otrzymane sygnały są analizowane w celu obliczenia warunków weryfikacji wymagań. W badanym przypadku przeprowadzana jest analiza wysokości, aby określić położenie samolotu (czy znajduje się na postoju, czy w locie). Do tego celu można używać również innych sygnałów i obliczanych parametrów modelu.

Warunki weryfikacji i sprawdzane parametry są przekazywane do standardowych bloków weryfikacyjnych, w których odbywa się analiza danych tych parametrów pod kątem zgodności z zadanymi wymaganiami. Wyniki są zapisywane w bazie danych sygnałów w taki sposób, aby można je było wykorzystać do automatycznego tworzenia list kontrolnych.

Rysunek 5. Struktura arkusza obliczeniowego weryfikacji wymagań.

Jako sprawdzane parametry niekoniecznie muszą być używane sygnały znajdujące się w bazie danych, którymi zarządzają parametry, obliczane w trakcie modelowania. Nic nie stoi na przeszkodzie, aby w ramach projektu wymagań przeprowadzić dodatkowe obliczenia, tak jak obliczamy warunki weryfikacji.

Na przykład takie wymaganie:

Liczba włączeń systemu korekcyjnego w trakcie lotu do celu nie powinna przekraczać 5, a łączny czas pracy systemu korekcyjnego nie powinien być dłuższy niż 30 sekund.

W takim przypadku do obliczeniowego schematu projektu wymagań dodawany jest algorytm licznika liczby włączeń i łącznego czasu pracy.

Standardowy blok weryfikacji wymagań.

Każdy standardowy blok weryfikacji wymagań jest przeznaczony do obliczania spełnienia wymogu określonego rodzaju. Na przykład w wymaganiach dotyczących środowiska występuje zakres roboczych temperatur otoczenia w czasie postoju i w locie. Ten blok powinien otrzymać jako parametr temperaturę powietrza w modelu i określić, czy ten parametr pokrywa zadany zakres temperatur.

Blok zawiera dwa porty wejściowe, param i condition.

Na pierwszy port podawany jest sprawdzany parametr. W tym przypadku jest to „Temperatura otoczenia”.

Na drugi port podawana jest zmienna logiczna – warunek wykonania weryfikacji.

Jeżeli na drugi wejście dociera TRUE (1), to blok wykonuje obliczenie weryfikacji wymagań.

Jeśli drugi wejście otrzymuje FALSE (0), to warunki sprawdzania nie są spełnione. Jest to niezbędne, aby można było uwzględnić warunki obliczeń. W naszym przypadku to wejście jest używane do włączania lub wyłączania kontroli w zależności od stanu modelu. Jeśli statek powietrzny podczas modelowania znajduje się na ziemi, to wymagania dotyczące lotu nie są sprawdzane, i odwrotnie – jeśli statek powietrzny jest w powietrzu, to nie są sprawdzane wymagania związane z pracą na postoju.

To wejście można również wykorzystać podczas konfigurowania modelu, na przykład na początkowym etapie obliczeń. Gdy model jest dostosowywany do wymaganych warunków, bloki kontrolne są wyłączone, ale gdy tylko system osiąga wymagany tryb pracy, bloki kontrolne są włączane.

Parametrami tego bloku są:

• warunki brzegowe: górny (UpLimit) i dolny (DownLimit) zakres, który powinien być sprawdzony;
• wymagany czas utrzymania systemu w granicach brzegowych (TimeInterval) w sekundach;
• identyfikator wymagania ReqName;
• dozwolenie na przekroczenie zakresu Out_range – zmienna boolean, która określa, czy naruszenie wymagań następuje w wyniku przekroczenia wartości poza sprawdzany zakres.

W niektórych przypadkach przekroczenie sprawdzanej wartości oznacza, że system ma zapas i może działać poza zakresem roboczym. W innych przypadkach przekroczenie oznacza, że system nie jest w stanie utrzymać wymaganych parametrów w ramach zakresu.

Rysunek 6. Typowy blok sprawdzania właściwości na schemacie oraz jego parametry.

W wyniku obliczeń tego bloku na wyjściu powstaje zmienna Result, która przyjmuje następujące wartości:

• 0 – rNone, wartość nieokreślona;
• 1 – rDone, wymaganie spełnione;
• 2 – rFault, wymaganie niespełnione.

Obraz bloku zawiera:

• tekst identyfikatora;
• cyfrowe wyświetlenia parametrów granic pomiarowych;
• kolorowy identyfikator stanu parametru.

Wewnątrz bloku może znajdować się dość skomplikowany schemat wnioskowania logicznego.

Na przykład, aby sprawdzić roboczy zakres temperatur bloku przedstawionego na rysunku 6, wewnętrzny schemat przedstawiony jest na rysunku 7.

Rysunek 7. Wewnętrzny schemat bloku określania zakresu temperatur.

Wewnątrz bloku schematy używają właściwości określonych w parametrach bloku.
Oprócz analizy zgodności wymagań, wewnętrzny schemat bloku zawiera wykres, który jest potrzebny do przedstawienia wyników symulacji. Ten wykres może być użyty zarówno do podglądu w czasie obliczeń, jak i do analizy wyników po obliczeniach.

Wyniki obliczeń są przekazywane na wyjście bloku i jednocześnie zapisywane do wspólnego pliku raportu, który jest tworzony na podstawie wyników w całym projekcie. (zob. rys. 8)

Przykład raportu utworzonego na podstawie wyników symulacji to plik html, utworzony zgodnie z określonym formatem. Format może być dowolnie dostosowany do formatu przyjętego w konkretnej organizacji.

Wewnątrz bloku schematy używają właściwości określonych w parametrach bloku.
Oprócz analizy zgodności wymagań, wewnętrzny schemat bloku zawiera wykres, który jest potrzebny do przedstawienia wyników symulacji. Ten wykres może być użyty zarówno do podglądu w czasie obliczeń, jak i do analizy wyników po obliczeniach.

Wyniki obliczeń są przekazywane na wyjście bloku i jednocześnie zapisywane do wspólnego pliku raportu, który jest tworzony na podstawie wyników w całym projekcie. (zob. rys. 8)

Przykład raportu utworzonego na podstawie wyników symulacji to plik html, utworzony zgodnie z określonym formatem. Format może być dowolnie dostosowany do formatu przyjętego w konkretnej organizacji.

Rysunek 8. Przykład pliku raportu z wynikami symulacji.

W tym przykładzie konfiguracja formy raportu jest realizowana bezpośrednio w właściwościach projektu, a format jest określany w tabeli jako globalne sygnały projektu. W takim przypadku SimInTech sam rozwiązuje zadanie konfiguracji raportu, a blok zapisu wyników do pliku wykorzystuje te wiersze do zapisu w pliku raportu.

Rysunek 9. Konfiguracja formatu raportu w globalnych sygnałach projektu.

Wykorzystanie bazy danych sygnałów dla wymagań.

Dla automatyzacji pracy z ustawieniami właściwości dla każdego typowego bloku tworzona jest typowa struktura w bazie danych sygnałów. (zob. rys. 10)

Rysunek 10. Przykład struktury bloku weryfikacji wymagań w bazie danych sygnałów.

Baza danych sygnałów zapewnia:

• Przechowywanie wszystkich niezbędnych parametrów wymagań systemowych.
• Wygodny podgląd istniejących w projekcie wymagań z określonych parametrów i bieżących wyników symulacji.
• Konfigurację jednego bloku, grupy bloków z wykorzystaniem języka skryptowego. Zmiany w bazie danych sygnałów prowadzą do zmiany wartości właściwości bloku na schemacie.
• Przechowywanie opisów tekstowych, odwołań do punktów w specyfikacji wymagań lub identyfikatorów w systemie zarządzania wymaganiami.

Struktury bazy danych sygnałów dla wymagań mogą być łatwo dostosowane do współpracy z zewnętrznym systemem zarządzania wymaganiami. Ogólny schemat interakcji z systemami zarządzania wymaganiami przedstawiono na rysunku 11.

Rysunek 11. Schemat interakcji z systemem zarządzania wymaganiami.

Sekwencja interakcji testowego projektu SimInTech z systemem zarządzania wymaganiami jest następująca:

1. Dokumentacja techniczna jest dzielona na wymagania.
2. Wyodrębniane są takie wymagania dokumentacji technicznej, które mogą być weryfikowane poprzez matematyczne modelowanie procesów technicznych.
3. Atrybuty wyodrębnionych wymagań są przekazywane do bazy danych sygnałów SimInTech w strukturach standardowych bloków (na przykład maksymalna i minimalna temperatura).
4. W trakcie obliczeń dane struktur są przekazywane do schematów obliczeniowych bloków, przeprowadzana jest analiza, a wyniki są zapisywane w bazie danych sygnałów.
5. Po zakończeniu obliczeń wyniki analizy są przekazywane do systemu zarządzania wymaganiami.

Etapy pracy z wymaganiami 3–5 mogą być powtarzane w trakcie procesu projektowania, gdy zachodzą zmiany w konstrukcji i (lub) wymaganiach i, w związku z tym, konieczna jest ponowna weryfikacja wpływu wprowadzonych zmian.

Wnioski.

• Stworzony prototyp systemu zapewnia znaczną redukcję czasu analizy istniejących modeli pod kątem zgodności z wymaganiami dokumentacji technicznej.
• Proponowana technologia testowania wykorzystuje już istniejące modele dynamiczne i może być stosowana nawet dla wszelkich modeli dynamicznych, w tym wykonanych nie w środowisku SimInTech.
• Wykorzystanie pakietowej organizacji danych pozwala na tworzenie pakietów weryfikacji wymagań równolegle z opracowywaniem modeli, a nawet wykorzystanie tych pakietów jako dokumentacji technicznej do opracowania modeli.
• Technologia może być zintegrowana z istniejącymi systemami zarządzania wymaganiami bez znacznych kosztów.

Dla tych, którzy przeczytali do końca, link do wideo z prezentacją działania prototypu.

Źródło: habr.com