Kontynuując temat , spójrzmy na problem modelowania matematycznego od drugiej strony. Kiedy już jesteśmy przekonani, że model odpowiada domniemanej prawdzie życia, możemy odpowiedzieć na główne pytanie: „co właściwie tu mamy?” Tworząc model obiektu technicznego zazwyczaj chcemy mieć pewność, że obiekt ten spełni nasze oczekiwania. W tym celu przeprowadza się dynamiczne obliczenia procesów, a wynik porównuje z wymaganiami. To cyfrowy bliźniak, wirtualny prototyp itp. modnych maluchów, którzy już na etapie projektowania rozwiązują problem tego, jak mieć pewność, że otrzymamy to, co zaplanowaliśmy.
Jak możemy szybko upewnić się, że nasz system jest dokładnie tym, co projektujemy, czy nasz projekt będzie latał czy pływał? A jeśli leci, jak wysoko? A jeśli pływa, jak głęboko?
W artykule omówiono automatyzację weryfikacji zgodności z wymaganiami obiektu technicznego przy tworzeniu modeli dynamicznych systemów technicznych. Jako przykład przyjrzyjmy się elementowi specyfikacji technicznej układu chłodzenia powietrzem samolotu.
Uwzględniamy te wymagania, które można wyrazić liczbowo i zweryfikować matematycznie w oparciu o konkretny model obliczeniowy. Wiadomo, że to tylko część ogólnych wymagań stawianych każdemu systemowi technicznemu, jednak to właśnie na ich sprawdzeniu tracimy czas, nerwy i pieniądze na tworzenie dynamicznych modeli obiektu.
Opisując wymagania techniczne w formie dokumentu, można wyróżnić kilka rodzajów różnych wymagań, z których każde wymaga innego podejścia do tworzenia automatycznej weryfikacji spełnienia wymagań.
Rozważmy na przykład ten mały, ale realistyczny zestaw wymagań:
- Temperatura powietrza atmosferycznego na wejściu do stacji uzdatniania wody:
na parkingu - od minus 35 do 35 ºС,
w locie - od minus 35 do 39 ºС. - Ciśnienie statyczne powietrza atmosferycznego w locie wynosi od 700 do 1013 GPa (od 526 do 760 mm Hg).
- Całkowite ciśnienie powietrza na wejściu do czerpni SVO w locie wynosi od 754 do 1200 GPa (od 566 do 1050 mm Hg).
- Temperatura powietrza chłodzącego:
na parkingu – 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. - Przepływ powietrza chłodzącego:
na postoju – co najmniej 708 kg/h,
w locie – nie mniej niż 660 kg/h. - Temperatura powietrza w przedziałach przyrządów nie przekracza 60 ºС.
- Ilość drobnej, wolnej wilgoci w powietrzu chłodzącym nie przekracza 2 g/kg suchego powietrza.
Nawet w ramach tego ograniczonego zestawu wymagań istnieją co najmniej dwie kategorie, które należy traktować w systemie w różny sposób:
- wymagania dotyczące warunków pracy systemu (punkty 1-3);
- wymagania parametryczne dla systemu (pkt. 3-7).
Wymagania dotyczące warunków pracy systemu
Warunki zewnętrzne układu tworzonego w trakcie modelowania można określić jako warunki brzegowe lub jako wynik działania układu ogólnego.
W symulacji dynamicznej konieczne jest zapewnienie uwzględnienia w procesie symulacji określonych warunków pracy.
Parametryczne wymagania systemowe
Wymagania te są parametrami dostarczanymi przez sam system. Podczas procesu 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ń
Aby ułatwić pracę z wymaganiami, istniejące standardy zalecają przypisanie identyfikatora do każdego wymagania. Przy nadawaniu identyfikatorów wysoce pożądane jest zastosowanie jednolitego systemu kodowania.
Kod wymagania może być po prostu liczbą reprezentującą numer zamówienia wymagania lub może zawierać kod rodzaju wymagania, kod systemu lub jednostki, do której się odnosi, kod parametru, kod lokalizacji i cokolwiek innego, co inżynier może sobie wyobrazić. (zobacz artykuł dotyczący stosowania kodowania)
Tabela 1 przedstawia prosty przykład kodowania wymagań.
- kod źródła wymagań R-wymagania TK;
- kod rodzaj wymagań E - wymagania - parametry środowiskowe, czyli warunki pracy
S - wymagania stawiane przez system; - kod statusu statku powietrznego 0 – dowolny, G – zaparkowany, F – w locie;
- parametr fizyczny kod typu T – temperatura, P – ciśnienie, G – natężenie przepływu, wilgotność H;
- numer seryjny wymagania.
| ID Wymagania |
Opis | Parametr |
| REGT01 | Temperatura powietrza otoczenia przy wejściu do układu chłodzenia wodą: na parkingu - od minus 35°С. do 35°C. | |
| REFT01 | Temperatura powietrza atmosferycznego na wejściu do systemu obrony powietrznej: w locie - od minus 35 ºС do 39 ºС. | |
| REFP01 | Statyczne ciśnienie atmosferyczne w locie wynosi od 700 do 1013 hPa (od 526 do 760 mm Hg). | |
| REFP02 | Całkowite ciśnienie powietrza na wejściu do czerpni SVO w locie wynosi od 754 do 1200 hPa (od 566 do 1050 mm Hg). | |
| RSGT01 | Temperatura powietrza chłodzącego: podczas postoju nie więcej niż 27 ºС | |
| RSGT02 | Temperatura powietrza chłodzącego: na parkingu, dla jednostek technicznych nie więcej niż 29 şС | |
| RSFT01 | Temperatura powietrza chłodzącego w locie nie większa niż 25 ºС | |
| RSFT02 | Temperatura powietrza chłodzącego: w locie, dla zespołów technicznych nie więcej niż 27 şС | |
| RSGG01 | Przepływ powietrza chłodzącego: na postoju nie mniej niż 708 kg/h | |
| RSFG01 | Przepływ powietrza chłodzącego: w locie nie mniej niż 660 kg/h | |
| RS0T01 | Temperatura powietrza w przedziałach przyrządów nie większa niż 60 ºС | |
| RSH01 | Ilość drobnej, wolnej wilgoci w powietrzu chłodzącym nie przekracza 2 g/kg suchego powietrza |
Projekt systemu weryfikacji wymagań.
Dla każdego wymagania projektowego istnieje algorytm oceny zgodności parametrów projektowych z parametrami określonymi w wymaganiu. Ogólnie rzecz biorąc, każdy system sterowania zawsze domyślnie zawiera algorytmy sprawdzania wymagań. I nawet każdy regulator je zawiera. Jeżeli temperatura przekroczy dopuszczalny zakres, klimatyzator włączy się. Zatem pierwszym etapem każdej regulacji jest sprawdzenie, czy parametry spełniają wymagania.
A skoro weryfikacja jest algorytmem, to możemy posługiwać się tymi samymi narzędziami i narzędziami, których używamy do tworzenia programów sterujących. Przykładowo środowisko SimInTech umożliwia tworzenie pakietów projektów zawierających różne części modelu, realizowanych w formie odrębnych projektów (model obiektowy, model układu sterowania, model środowiska itp.).
Projekt weryfikacji wymagań w tym przypadku staje się tym samym projektem algorytmu i jest podłączony do pakietu modelowego. Natomiast w trybie modelowania dynamicznego przeprowadza analizę pod kątem zgodności z wymaganiami specyfikacji technicznych.
Możliwy przykład projektu systemu pokazano na rysunku 1.
Rysunek 1. Przykład projektu projektu weryfikacyjnego.
Podobnie jak w przypadku algorytmów sterowania, wymagania można sporządzić w formie zbioru arkuszy. Dla wygody pracy z algorytmami w środowiskach modelowania konstrukcji takich jak SimInTech, Simulink, AmeSim wykorzystano możliwość tworzenia konstrukcji wielopoziomowych w postaci podmodeli. Organizacja ta umożliwia grupowanie różnych wymagań w zbiory, co upraszcza pracę z szeregiem wymagań, tak jak ma to miejsce w przypadku algorytmów sterowania (patrz rys. 2).
Rysunek 2. Hierarchiczna struktura modelu weryfikacji wymagań.
Przykładowo w rozpatrywanym przypadku wyróżnia się dwie grupy: wymagania dla otoczenia i wymagania bezpośrednio dla systemu. Dlatego stosuje się dwupoziomową strukturę danych: dwie grupy, z których każda jest liściem algorytmu.
Do połączenia danych z modelem wykorzystuje się standardowy schemat generowania bazy sygnałów, w której przechowywane są dane do wymiany pomiędzy częściami projektu.
Podczas tworzenia i testowania oprogramowania w tej bazie danych umieszczane są odczyty czujników (analogi rzeczywistych czujników systemowych), które są wykorzystywane przez system sterowania.
W przypadku projektu testowego dowolne parametry obliczone w modelu dynamicznym można zapisać w tej samej bazie danych i w ten sposób wykorzystać do sprawdzenia, czy wymagania zostały spełnione.
W tym przypadku sam model dynamiczny można wykonać w dowolnym systemie modelowania matematycznego lub nawet w postaci programu wykonywalnego. Jedynym wymaganiem jest obecność interfejsów oprogramowania do wydawania danych modelowania do środowiska zewnętrznego.
Rysunek 3. Podłączenie projektu weryfikacji do modelu złożonego.
Przykład podstawowego arkusza weryfikacji wymagań przedstawiono na rysunku 4. Z punktu widzenia dewelopera jest to konwencjonalny diagram obliczeniowy, na którym w formie graficznej przedstawiono algorytm weryfikacji wymagań.
Rysunek 4. Arkusz kontroli wymagań.
Główne części arkusza kontrolnego opisano na rysunku 5. Algorytm sprawdzający jest zbudowany podobnie jak diagramy projektowe algorytmów sterowania. Po prawej stronie znajduje się blok umożliwiający odczyt sygnałów z bazy danych. Blok ten uzyskuje dostęp do bazy danych sygnałów podczas symulacji.
Odebrane sygnały są analizowane w celu obliczenia warunków weryfikacji wymagań. W takim przypadku przeprowadzana jest analiza wysokości w celu ustalenia pozycji statku powietrznego (czy jest on zaparkowany, czy w locie). W tym celu można wykorzystać inne sygnały i obliczone parametry modelu.
Warunki weryfikacji i sprawdzane parametry przenoszone są do standardowych bloków weryfikacyjnych, w których parametry te są analizowane pod kątem zgodności z określonymi wymaganiami. Wyniki zapisywane są w bazie sygnałów w sposób umożliwiający automatyczne wygenerowanie listy kontrolnej.
Rysunek 5. Struktura arkusza kalkulacyjnego weryfikacji wymagań.
Badane parametry niekoniecznie korzystają z sygnałów zawartych w bazie danych, którymi sterują parametry wyliczane w procesie symulacji. Nic nie stoi na przeszkodzie, aby w ramach projektu wymagań przeprowadzić dodatkowe obliczenia, tak samo jak obliczamy warunki weryfikacji.
Na przykład ten wymóg:
Liczba uruchomień systemu korekcji podczas lotu do celu nie powinna przekraczać 5, a łączny czas działania systemu korekcji nie powinien przekraczać 30 sekund.
W takim przypadku do diagramu projektowego wymagań dodawany jest algorytm zliczania liczby uruchomień i całkowitego czasu pracy.
Typowy blok weryfikacji wymagań.
Każde pole wyboru wymagania standardowego służy do obliczania spełnienia wymagania określonego typu. Na przykład wymagania środowiskowe obejmują zakres temperatur otoczenia podczas postoju i podczas lotu. Blok ten musi jako parametr przyjąć temperaturę powietrza w modelu i określić, czy parametr ten mieści się w zadanym zakresie temperatur./p>
Blok zawiera dwa porty wejściowe, parametr i warunek.
Pierwsza zasilana jest sprawdzanym parametrem. W tym przypadku „temperatura zewnętrzna”.
Na drugi port podawana jest zmienna logiczna – warunek przeprowadzenia kontroli.
Jeżeli na drugim wejściu odebrana zostanie wartość PRAWDA (1), wówczas blok wykonuje obliczenia sprawdzające wymagania.
Jeżeli na drugie wejście zostanie wyświetlony komunikat FAŁSZ (0), wówczas warunki testu nie są spełnione. Jest to konieczne, aby można było uwzględnić warunki obliczeniowe. W naszym przypadku to wejście służy do włączania lub wyłączania sprawdzania w zależności od stanu modelu. Jeżeli w czasie symulacji statek powietrzny znajduje się na ziemi, to nie sprawdza się wymagań związanych z lotem i odwrotnie – jeżeli statek powietrzny jest w locie, to nie sprawdza się wymagań związanych z pracą na stanowisku postojowym.
Dane wejściowe można wykorzystać także podczas konfiguracji modelu, np. na początkowym etapie obliczeń. Po doprowadzeniu modelu do wymaganego stanu bloki kontrolne są wyłączane, ale gdy tylko system osiągnie wymagany tryb pracy, bloki kontrolne są włączane.
Parametry tego bloku to:
- warunki brzegowe: górna (UpLimit) i dolna (DownLimit) granica zakresu, którą należy sprawdzić;
- wymagany czas ekspozycji systemu w zakresach granicznych (TimeInterval) w sekundach;
- Identyfikator żądania Nazwa żądania;
- dopuszczalność przekroczenia zakresu Out_range jest zmienną logiczną, która określa, czy wartość przekraczająca sprawdzany zakres stanowi naruszenie wymagania.
W niektórych przypadkach wartość testowa wskazuje, że system ma pewien margines i może działać poza swoim zakresem roboczym. W innych przypadkach wyjście oznacza, że system nie jest w stanie utrzymać wartości zadanych w odpowiednim zakresie.
Rysunek 6. Typowy blok sprawdzania właściwości na schemacie i jego parametry.
W wyniku obliczenia tego bloku na wyjściu tworzona jest zmienna Result, która przyjmuje następujące wartości:
- 0 – rNone, wartość nie zdefiniowana;
- 1 – rGotowe, wymaganie jest spełnione;
- 2 – rBłąd, wymaganie nie jest spełnione.
Obraz blokowy zawiera:
- tekst identyfikatora;
- cyfrowe wyświetlacze parametrów limitów pomiarowych;
- kolorowy identyfikator stanu parametru.
Wewnątrz bloku może znajdować się dość złożony obwód wnioskowania logicznego.
Na przykład, aby sprawdzić zakres temperatur roboczych urządzenia pokazany na rysunku 6, obwód wewnętrzny pokazano na rysunku 7.
Rysunek 7. Schemat wewnętrzny jednostki wyznaczającej zakres temperatur.
Wewnątrz bloku obwodu wykorzystywane są właściwości określone w parametrach bloku.
Oprócz analizy zgodności z wymaganiami, wewnętrzny diagram bloku zawiera wykres niezbędny do wyświetlenia wyników symulacji. Wykres ten można wykorzystać zarówno do przeglądania podczas obliczeń, jak i do analizy wyników po obliczeniu.
Wyniki obliczeń przesyłane są na wyjście bloku i jednocześnie zapisywane są w ogólnym pliku raportu, który tworzony jest na podstawie wyników dla całego projektu. (patrz rys. 8)
Przykładem raportu utworzonego na podstawie wyników symulacji jest plik HTML utworzony według zadanego formatu. Format można dowolnie skonfigurować do formatu akceptowanego przez konkretną organizację.
Wewnątrz bloku obwodu wykorzystywane są właściwości określone w parametrach bloku.
Oprócz analizy zgodności z wymaganiami, wewnętrzny diagram bloku zawiera wykres niezbędny do wyświetlenia wyników symulacji. Wykres ten można wykorzystać zarówno do przeglądania podczas obliczeń, jak i do analizy wyników po obliczeniu.
Wyniki obliczeń przesyłane są na wyjście bloku i jednocześnie zapisywane są w ogólnym pliku raportu, który tworzony jest na podstawie wyników dla całego projektu. (patrz rys. 8)
Przykładem raportu utworzonego na podstawie wyników symulacji jest plik HTML utworzony według zadanego formatu. Format można dowolnie skonfigurować do formatu akceptowanego przez konkretną organizację.
Rysunek 8. Przykład pliku raportu na podstawie wyników symulacji.
W tym przykładzie formularz raportu konfiguruje się bezpośrednio we właściwościach projektu, a format w tabeli ustawia się jako globalne sygnały projektu. W tym przypadku SimInTech sam rozwiązuje problem ustawienia raportu, a blok zapisu wyników do pliku wykorzystuje te linie do zapisu do pliku raportu.
Rysunek 9. Ustawianie formatu raportu w globalnych sygnałach projektu
Korzystanie z bazy sygnałów dla wymagań.
Aby zautomatyzować pracę z ustawieniami właściwości, w bazie sygnałów tworzona jest standardowa struktura dla każdego typowego bloku. (patrz rys. 10)
Rysunek 10. Przykład struktury bloku sprawdzania wymagań w bazie danych sygnałów.
Baza danych Signal zapewnia:
- Przechowywanie wszystkich niezbędnych parametrów wymagań systemowych.
- Wygodne przeglądanie istniejących wymagań projektowych na podstawie określonych parametrów i bieżących wyników modelowania.
- Konfigurowanie jednego bloku lub grupy bloków przy użyciu skryptowego języka programowania. Zmiany w bazie sygnałów prowadzą do zmian wartości właściwości bloku na schemacie.
- Przechowywanie opisów tekstowych, linków do pozycji specyfikacji technicznych lub identyfikatorów w systemie zarządzania wymaganiami.
Struktury bazy danych Signal dla wymagań można łatwo skonfigurować do współpracy z systemem zarządzania wymaganiami innej firmy.Ogólny schemat interakcji z systemami zarządzania wymaganiami przedstawiono na rysunku 11.
Rysunek 11. Schemat interakcji z systemem zarządzania wymaganiami.
Sekwencja interakcji pomiędzy projektem testowym SimInTech a systemem kontroli wymagań jest następująca:
- Zakres wymagań i obowiązków jest podzielony na wymagania.
- Zidentyfikowano wymagania specyfikacji technicznych, które można zweryfikować poprzez modelowanie matematyczne procesów technicznych.
- Atrybuty wybranych wymagań przekazywane są do bazy sygnałów SimInTech w strukturze bloków standardowych (np. temperatura maksymalna i minimalna).
- Podczas procesu obliczeń dane konstrukcji są przenoszone na schematy projektowe bloków, przeprowadzana jest analiza, a wyniki zapisywane są w bazie danych sygnałów.
- Po zakończeniu obliczeń wyniki analiz przekazywane są do systemu zarządzania wymaganiami.
Etapy wymagań od 3 do 5 można powtórzyć w procesie projektowania, gdy pojawią się zmiany w projekcie i/lub wymaganiach i konieczne będzie ponowne przetestowanie wpływu tych zmian.
Wnioski.
- Stworzony prototyp systemu zapewnia znaczne skrócenie czasu analizy istniejących modeli pod kątem zgodności z wymaganiami specyfikacji technicznych.
- Proponowana technologia testowania wykorzystuje już istniejące modele dynamiczne i może być stosowana nawet do dowolnych modeli dynamicznych, także tych nie wykonywanych w środowisku SimInTech.
- Korzystanie z organizacji danych wsadowych umożliwia tworzenie pakietów weryfikacji wymagań równolegle z opracowywaniem modelu, a nawet używanie tych pakietów jako specyfikacji technicznych do opracowywania modelu.
- Technologię można zintegrować z istniejącymi systemami zarządzania wymaganiami bez znacznych kosztów.
Dla tych, którzy przeczytali do końca,
Źródło: www.habr.com