Visual Paradigm Desktop | 
Visual Paradigm Online
Inżynieria złożonych systemów wymaga więcej niż tylko projektowania elementów; wymaga ścisłego połączenia między intencją a realizacją. W miarę jak systemy rosną w zakresie, łącząc oprogramowanie, sprzęt, struktury mechaniczne i logikę operacyjną, rośnie ryzyko fragmentacji. Inżynieria oparta na modelach systemów (MBSE) z wykorzystaniem SysML zapewnia ramy do zarządzania tą złożonością, ale tylko wtedy, gdy śledzenie zostanie poprawnie zainicjowane. Niniejszy przewodnik bada wzorce strukturalne niezbędne do utrzymania spójnej definicji systemu w różnych dziedzinach inżynierskich.
Śledzenie w SysML to nie tylko funkcja raportowania; jest ono fundamentem weryfikacji i walidacji. Bez silnych połączeń między wymaganiami, elementami projektu i testami architektura systemu staje się zbiorem izolowanych wysp. Inżynierowie muszą rozumieć, jak wykorzystać język, aby tworzyć trwałe połączenia, które przetrwają iteracje projektowe i przekazywanie między dziedzinami.
Zanim zastosuje się wzorce, należy zrozumieć podstawowe mechanizmy w języku. SysML definiuje śledzenie przede wszystkim poprzezśledzenierelację, która może być stosowana między różnymi elementami. Ta relacja różni się od standardowych połączeń strukturalnych lub behawioralnych.
Elementy wymagań: Określają, co system musi robić. Są one punktami wzorcowymi sieci śledzenia.
Diagramy definicji bloków (BDD): Określają strukturę fizyczną i logiczną.
Diagramy wewnętrznych bloków (IBD): Określają wewnętrzne interfejsy i przepływy.
Diagramy parametryczne: Określają ograniczenia i relacje matematyczne.
Testy weryfikacyjne: Często reprezentowane jako typy wymagań lub osobne wymagania weryfikacyjne.
Głównym założeniem śledzenia jest zapewnienie, że każde wymaganie jest spełnione przez element projektu i zweryfikowane przez przypadek testowy. Tworzy to zamknięty cykl dowodów. W systemach wielodziedzinowych ten cykl musi obejmować różne języki techniczne i dziedziny inżynierskie.
Różne pytania inżynierskie wymagają różnych wzorców śledzenia. Ogólna metoda często prowadzi do zamieszania lub niewystarczającej widoczności. Poniżej znajdują się główne wzorce używane do strukturyzowania informacji systemowych.
Śledzenie w przód zaczyna się od wymagania i porusza się w dół, ku projektowaniu i realizacji. Odpowiada na pytanie:„Które elementy projektu spełniają to wymaganie?”
Kierunek: Wymaganie → Projekt → Realizacja.
Przypadek użycia: Zapewnienie, że żadne wymaganie nie zostanie pominięte.
Zalety: Zapobiega rozszerzaniu zakresu poprzez potwierdzenie, że każdy żądany element jest uwzględniony w architekturze.
Realizacja: Użyj deriveReqt lub refine relacje, aby połączyć wymagania z blokami lub przypadkami użycia.
Śledzenie wsteczne przemieszcza się w górę od elementu projektowego do pierwotnego wymagania. Odpowiada na pytanie: „Dlaczego ten składnik istnieje?”
Kierunek: Projektowanie/Realizacja → Wymaganie.
Przypadek użycia:Identyfikacja nadmiarowych elementów lub martwego kodu w modelu.
Zalety: Wspiera zarządzanie zmianami, pokazując, które wymagania zostaną dotknięte, jeśli określony składnik zostanie zmodyfikowany.
Wdrożenie: Połącz bloki w IBD z konkretnymi wymaganiami na diagramie wymagań.
Ten wzorzec łączy linki w przód i wstecz, tworząc kompletną łańcuch sprawdzania. Jest to standard złota dla systemów krytycznych dla bezpieczeństwa.
Kierunek: Wymaganie ↔ Projekt ↔ Test.
Przypadek użycia: Procesy certyfikacji i zgodność z przepisami.
Zalety: Zapewnia pełną gwarancję pokrycia podczas audytów i przypadków bezpieczeństwa.
W systemach wielodomenowych wymaganie oprogramowania musi być powiązane z blokiem sprzętowym, który jest powiązany z ograniczeniem mechanicznym. Ten wzorzec zamyka przerwę między różnymi językami inżynierskimi.
Kierunek: Wymaganie oprogramowania → Firmware → Blok elektryczny → Ograniczenie mechaniczne.
Przypadek użycia: Systemy cyber-fizyczne, w których zachowanie zależy od właściwości fizycznych.
Zalety:Zapewnia, że funkcja oprogramowania nie narusza ograniczenia fizycznego.
Układanie tych wzorców wymaga strukturalnego podejścia. Format macierzy jest często najskuteczniejszym sposobem wizualizacji relacji. Poniższa tabela przedstawia zalecane kolumny dla kompleksowej macierzy śledzenia.
|
Identyfikator wymagania |
Tekst wymagania |
Źródło |
Identyfikator elementu projektowego |
Typ elementu projektowego |
Metoda weryfikacji |
Identyfikator przypadku testowego |
Status |
|---|---|---|---|---|---|---|---|
|
REQ-001 |
System ma rozpocząć sekwencję uruchomienia |
Uczestnik |
BLOCK-100 |
Logika sterowania |
Analiza |
TEST-001 |
Weryfikowane |
|
REQ-002 |
Zużycie mocy < 5W |
Regulacyjne |
PARAM-200 |
Ograniczenie |
Symulacja |
TEST-002 |
W trakcie |
|
REQ-003 |
Obudowa musi wytrzymać uderzenie |
Środowiskowy |
MECH-300 |
Część mechaniczna |
Test fizyczny |
TEST-003 |
Zatwierdzony |
Używanie strukturalnej macierzy zapewnia, że żadna kolumna nie zostanie pominięta podczas procesu przeglądu. Przynuca inżyniera do rozważenia metody weryfikacji dla każdego pojedynczego wymagania.
Złożone systemy rzadko składają się z jednej dziedziny inżynierskiej. Dotykają one interakcji między oprogramowaniem, elektroniką, mechaniką i operacjami. Każda dziedzina ma swój własny cykl życia i terminologię, co utrudnia śledzenie.
Najczęstszy punkt napięcia pojawia się tam, gdzie oprogramowanie spotyka się ze sprzętem. Wymaganie oprogramowania może brzmieć: „System ma odpowiadać w ciągu 50 ms”. Jest to abstrakcja. Musi być przypisane do bloku sprzętowego, który określa szybkość procesora i opóźnienie pamięci.
Wzorzec: Użyj wyróżnij połączenie z wymagania oprogramowania do bloku funkcyjnego w definicji sprzętu.
Wyzwanie: Ograniczenia czasowe są często definiowane na diagramach parametrycznych, podczas gdy logika jest definiowana w maszynach stanów.
Rozwiązanie: Utwórz dedykowany Blok interfejsu który jasno definiuje właściwości czasowe i łączy wymaganie oprogramowania z tym interfejsem.
Ograniczenia mechaniczne często wyznaczają limity operacyjne. Jeśli ramie mechaniczne ma maksymalny moment obrotowy, tryb operacyjny musi odzwierciedlać tę ograniczoną wartość.
Wzorzec: Połącz przypadki użycia operacyjne z blokami mechanicznymi, z którymi się oddziałują.
Wyzwanie: Wymagania operacyjne są często pisane językiem naturalnym, podczas gdy modele mechaniczne wykorzystują ograniczenia matematyczne.
Rozwiązanie: Przekształć limity operacyjne na ograniczenia parametryczne. Połącz wymaganie bezpośrednio z równaniem na diagramie parametrycznym.
Firmware często działa jako klej łączący oprogramowanie wysokiego poziomu z sygnałami fizycznymi niskiego poziomu. Śledzenie musi zapewnić, że sterownik firmware poprawnie ujawnia możliwości fizycznego czujnika.
Wzorzec:Użyj relacji przyporządkowania, aby przypisać funkcje firmware do konkretnych sterowników sprzętowych.
Wyzwanie:Aktualizacje firmware mogą odbywać się bez zmiany sprzętu fizycznego.
Rozwiązanie:Utrzymuj strategię wersjonowania w odniesieniu do linków śledzenia. Jeśli firmware ulega zmianie, ale wymaganie jest spełnione, aktualizuj stan linku zamiast zerwać połączenie.
Wprowadzanie śledzenia nie jest bez przeszkód. W złożonych środowiskach pojawiają się kilka typowych problemów. Wczesne rozpoznanie ich pozwala na lepsze planowanie.
W czasie, wraz z zmianami wymagań lub ewolucją projektu, linki stają się przestarzałe. Wymaganie może zostać usunięte, ale link nadal wskazuje na nieistniejący blok.
Zmniejszenie ryzyka:Wprowadź skrypty automatycznej weryfikacji, które sprawdzają istnienie nieprzypisanych linków podczas procesu kompilacji.
Zmniejszenie ryzyka:Wymagaj flagi stanu dla każdego linku (np. Aktywny, Przestarzały, Oczekujący).
Czasem wymaganie jest zbyt ogólne, aby móc je powiązać z pojedynczym składnikiem, albo składnik jest zbyt szczegółowy, aby móc go powiązać z pojedynczym wymaganiem. Powoduje to trudną do zarządzania relację wiele do wielu.
Zmniejszenie ryzyka:Rozłóż wymagania wysokiego poziomu na niższe wymagania funkcjonalne zgodne z blokami systemu.
Zmniejszenie ryzyka:Zgrupuj wiele składników niskiego poziomu w Blok złożony i zamiast tego powiąż z nim.
Inżynierowie oprogramowania używają innych narzędzi niż inżynierowie mechaniczni. Nie mogą widzieć tego samego kontekstu śledzenia.
Zmniejszenie ryzyka:Przyjmij repozytorium modelu jednej prawdy, które wspiera integrację z zewnętrznymi narzędziami dziedziny.
Zmniejszenie ryzyka:Ustanów wspólną konwencję nazewnictwa dla wszystkich elementów podlegających śledzeniu we wszystkich dziedzinach.
Utrzymanie śladów wymaga dyscypliny. Nie jest to jednorazowa konfiguracja, lecz ciągła działalność.
Zacznij wcześnie: Zdefiniuj wymagania dotyczące śladów w fazie koncepcji. Nie czekaj aż do fazy projektowania, by dodać linki.
Znormalizuj nazewnictwo: Używaj spójnego formatu identyfikatorów (np. REQ-SYS-001, BLK-INT-001). Dzięki temu możliwe staje się automatyczne wyszukiwanie i raportowanie.
Regularne audyty: Zaprojektuj kwartalne przeglądy grafu śladów. Sprawdź obecność uszkodzonych linków i wymagań bez spójnych linków.
Automatyzuj tam, gdzie to możliwe: Używaj wbudowanych funkcji weryfikacji modelu do wykrywania niezgodności. Unikaj ręcznej weryfikacji linków.
Zdokumentuj wzorzec: Stwórz standardowy procedurę operacyjną (SOP), która określa sposób tworzenia, etykietowania i utrzymywania linków.
Aby zapewnić, że sieć śladów jest zdrowa, należy śledzić konkretne metryki. Te metryki zapewniają przejrzystość jakości definicji systemu.
Ta metryka oblicza stosunek wymagań posiadających co najmniej jeden link w dół (projekt lub test).
Cel: 100% krytycznych wymagań musi mieć pokrycie.
Pomiar: (Wymagania z linkami / Łączna liczba wymagań) × 100.
Ta metryka mierzy stosunek wymagań powiązanych z metodą weryfikacji.
Cel: 100% wymagań musi mieć przypisaną metodę weryfikacji.
Pomiar: (Wymagania z testem/analizą / Łączna liczba wymagań) × 100.
Ta metryka śledzi tempo, z jakim linki są niszczone lub zmieniane w czasie.
Cel: Niskie tempo zmian wskazuje na stabilne wymagania.
Pomiar:(Złamane linki na miesiąc / Łączna liczba linków) × 100.
W systemach krytycznych dla bezpieczeństwa prosty link często jest niewystarczający. Wymagana jest hierarchiczna struktura weryfikacji, aby wykazać zgodność na każdym poziomie.
Poziom 1: Wymóg systemowy (np. „Pojezdzie musi zatrzymać się w odległości 100 m”).
Poziom 2: Wymóg podsystemu (np. „System hamulcowy musi wytworzyć siłę 500 N”).
Poziom 3: Wymóg elementu (np. „Pompa hydrauliczna musi przepływać 10 L/min”).
Poziom 4: Test wdrożenia (np. „Wynik testu przepływu pompy”).
Ta hierarchia zapewnia, że awaria na poziomie elementu może zostać śledzona do wymogu poziomu systemowego. Pozwala inżynierom dokładnie wskazać, gdzie wystąpiła awaria w łańcuchu logiki.
Zmiany są nieuniknione. Gdy zmienia się wymóg, analiza wpływu opiera się całkowicie na linkach śledzenia.
Analiza wpływu: Gdy wymóg jest modyfikowany, przejdź wszystkie linki w dół, aby zidentyfikować zafektowane bloki, interfejsy i testy.
Przepływ zatwierdzenia: Wymagaj zatwierdzenia ze wszystkich dotkniętych dziedzin przed zmianą wymogu. Na przykład zmiana wymogu oprogramowania może wymagać zatwierdzenia zespołu sprzętowego, jeśli wpływa na obciążenie procesora.
Kontrola wersji: Zachowaj historię grafu śledzenia. Jeśli link zostanie usunięty, powód musi zostać zarejestrowany.
Systemy rzeczywiste często pobierają dane z zewnętrznych źródeł, takich jak specyfikacje dostawców lub wyniki symulacji. Śledzenie w SysML powinno integrować te źródła.
Wymogi dostawcy: Połącz wewnętrzne wymogi z zewnętrznymi dokumentami dostawcy za pomocą relacji dokładnij relacji.
Wyniki symulacji: Dołącz pliki wyników symulacji do ograniczeń diagramu parametrycznego, aby udowodnić, że ograniczenie zostało spełnione.
Śledzenie problemów: Połącz błędy lub problemy z systemu śledzenia błędów bezpośrednio z wymogiem, który je spowodował.
Duże projekty często obejmują wiele modeli dla różnych podsystemów. Śledzenie musi być zachowane między granicami tych modeli.
Import modelu:Użyj pakietów odniesień do importu bloków z jednego modelu do drugiego, zachowując ich identyfikatory i linki śledzenia.
Definicja interfejsu:Zdefiniuj ściśle określone interfejsy między modelami. Śledzenie nie powinno przekraczać granic modeli poprzez nieprecyzyjne odniesienia.
Globalny rejestry:Utrzymuj centralny rejestry wszystkich wymagań i ich unikalnych identyfikatorów, aby zapobiec powielaniu się między modelami.
Tworzenie solidnej sieci śledzenia to inwestycja strategiczna. Zmniejsza koszty zmian, poprawia pewność weryfikacji i zapewnia jasne widoczność stanu systemu. Stosując powyższe wzorce, inżynierowie mogą zarządzać złożonością systemów wielodziedzinowych, nie tracąc przy tym z oczu pierwotnego celu.
Sukces w tej dziedzinie zależy od dyscypliny, automatyzacji oraz jasnego zrozumienia relacji między wymaganiami, projektem i weryfikacją. Traktuj graf śledzenia jako żywy artefakt, który rośnie i ewoluuje wraz z systemem. Regularna konserwacja i weryfikacja zapewnia, że model pozostaje wiarygodnym źródłem prawdy przez cały cykl życia projektu.