Wnioski z zarządzania wymaganiami: błędy konwersji jednostek

W rozwoju produktów sprzętowych inżynierowie codziennie posługują się liczbami. Wartość przechodzi od inżyniera do rysunku, od specyfikacji do części albo od Twojego zespołu do dostawcy. Przez większość czasu to działa, ponieważ wszyscy wiedzą, co dana liczba oznacza i jakiej jednostki używa.

Ryzyko pojawia się wtedy, gdy ta wartość przechodzi przez etap przekazania, a obie strony nie odczytują jej w ten sam sposób. Jedna strona może pracować w funtach, podczas gdy druga oczekuje kilogramów. Jeden dokument może używać starszego projektu w systemie imperialnym, podczas gdy nowy projekt jest metryczny. Liczba może wyglądać poprawnie po obu stronach, ale nie prowadzi już do tej samej decyzji.

Poniższe trzy historie inżynierskie pokazują, jak łatwo może do tego dojść:

Trzy przypadki, jeden schemat

Trzy awarie inżynieryjne z trzech dekad pokazują ten sam problem przekazania w różnych formach. W każdym przypadku liczba przeszła z jednej części procesu do drugiej. Dla użytkowników liczba wydawała się poprawna, ale w grze były dwa systemy miar. Na etapie przekazania nie wyjaśniono, której jednostki dotyczyła dana liczba.

Lot Air Canada 143: Gimli Glider

Pierwszym przykładem jest Gimli Glider z 1983 roku. Pokazuje on, co stało się, gdy linia lotnicza Air Canada przeszła z jednostek imperialnych na metryczne. Lot 143, Boeing 767 lecący z Montrealu do Edmonton, był ich pierwszym samolotem metrycznym.

Tego dnia system wskazywania ilości paliwa (FQIS) nie działał, więc załoga zmierzyła ilość paliwa ręcznie. Użyli wartości gęstości paliwa 1,77 podanej przez obsługę tankowania, wyrażonej w funtach na litr, co było standardem dla pozostałej części floty. Jednak metryczny 767 wymagał tej wartości w kilogramach na litr, gdzie poprawna liczba wynosiła około 0,8.

Samolot wystartował mając tylko połowę paliwa, jakiego spodziewała się załoga, co spowodowało zatrzymanie obu silników podczas lotu. Na szczęście piloci zdołali bezpiecznie wylądować.

Mars Climate Orbiter

Szesnaście lat później Mars Climate Orbiter został utracony z powodu błędu nawigacyjnego wynikającego z nieprzeliczenia jednostek anglosaskich na metryczne. Oprogramowanie Lockheed Martin przekazywało dane z silników manewrowych w funtosekundach siły. Oprogramowanie nawigacyjne NASA oczekiwało niutonosekund, które różnią się od funtosekund siły współczynnikiem 4,45.

Statek kosmiczny miał wejść na orbitę na wysokości od 150 do 200 kilometrów nad Marsem. Zamiast tego obniżył się do około 57 kilometrów i spłonął w atmosferze Marsa.

Kolejka górska Space Mountain w Tokyo Disneyland

W 2003 roku kolejka górska Space Mountain w Tokyo Disneyland pokazała podobny problem na przykładzie rysunków projektowych. W 1995 roku projekt został przerysowany z systemu imperialnego na metryczny, zmieniając średnicę osi z 44,14 na 45 milimetrów. Jednak starsze rysunki nie zostały wycofane z użycia i w rezultacie istniały dwa zestawy rysunków projektowych.

W 2002 roku, gdy ponownie zamówiono nowy zestaw osi, zamówienie oparto na wersji projektu sprzed 1995 roku. W rezultacie części miały zbyt mały wymiar. Ta różnica 0,86 milimetra sprawiła, że luz łożyska był znacznie większy niż zamierzono. Po miesiącach użytkowania oś pękła.

We wszystkich trzech przypadkach sama liczba nie wyglądała podejrzanie. Problem zaczynał się wtedy, gdy ta liczba stawała się podstawą kolejnego kroku inżynieryjnego, a jej jednostka lub źródło nie były wystarczająco jasno określone.

Ta ilustracja przypomina, że wartość może wyglądać poprawnie dla wszystkich, a mimo to być błędna: czy obie strony przekazania zgadzają się co do jednostki?

Czego zespoły sprzętowe mogą nauczyć się z tych historii

Większość zespołów sprzętowych nie lata samolotami ani nie wysyła statków kosmicznych. Ale podobne przekazania zdarzają się każdego dnia. Wartość przechodzi od wymagania do rysunku, od specyfikacji do części albo od Twojego zespołu do dostawcy. Na każdym etapie przekazania jednostka musi pozostać przy liczbie. Pomocne mogą być trzy praktyki:

Określaj jednostki przy każdej wartości wymagania

Sama liczba nie wystarczy. „45” nie mówi kolejnej osobie, co ma zbudować ani przetestować. „45 mm” nadaje liczbie znaczenie. Za każdym razem trzymaj jednostkę obok wartości. To nie jest detal formatowania; to część wymagania.

Przypisuj odpowiedzialność przy przekazaniach inżynieryjnych

Pomyłki związane z jednostkami często zdarzają się wtedy, gdy informacje przechodzą z jednego zespołu do drugiego. Jedna strona może pracować na podstawie jednego odniesienia, podczas gdy druga oczekuje innego. Takie przekazanie wymaga jasno określonego właściciela. Ktoś powinien sprawdzić system jednostek, format danych i dokument źródłowy, zanim wartość zostanie użyta dalej w procesie.

Utrzymuj śledzalność wymagań i dowodów

Gdy wartość się zmienia, zespół musi znaleźć wszystko, co od niej zależy. Oznacza to, że wymaganie, rysunek, część, test i dowód nie powinny istnieć jako odseparowane elementy. Śledzalność pomaga zespołowi zobaczyć, skąd pochodzi dana wartość, co z niej korzysta i co wymaga przeglądu, gdy się zmienia.

Jak pomaga połączony przepływ pracy nad wymaganiami

Lepszy przepływ pracy nad wymaganiami utrzymuje liczbę, jej jednostkę, jej właściciela i dokument źródłowy blisko siebie. Nie traktuje wartości jedynie jako luźnej liczby w arkuszu kalkulacyjnym, rysunku czy specyfikacji.

Ma to największe znaczenie na etapach przekazania. Gdy wartość przechodzi z wymagania do prac projektowych lub weryfikacji, kolejna osoba może zobaczyć, co ta wartość oznacza, jakiej jednostki używa i skąd pochodzi. Jeśli wartość się zmieni, zespół może też sprawdzić, co wymaga przeglądu.

Altium Requirements Portal wspiera taki sposób pracy, utrzymując wymagania, odpowiedzialność, śledzalność i działania weryfikacyjne w jednym współdzielonym środowisku. Nie zastępuje inżynierskiego osądu. Pomaga utrzymać widoczność jednostki, właściciela i powiązanego kontekstu inżynieryjnego, zanim wartość zostanie użyta dalej w procesie.

Najważniejsze wnioski

• Pomyłki związane z jednostkami często zaczynają się na etapach przekazania, gdy wartość trafia do innego zespołu, dokumentu lub systemu, a jej jednostka nie jest jasno określona.
• Zanim liczba pokieruje kolejnym krokiem inżynieryjnym, zespół powinien wiedzieć, skąd pochodzi i kto za nią odpowiada.
• Śledzalność pomaga zespołom zobaczyć, co zależy od danej wartości, zanim zostanie ona zmieniona lub przekazana dalej w procesie.

Czy każda liczba w Twoim projekcie jest kompletna?

Każdemu z tych incydentów można było zapobiec. Nie dzięki lepszej inżynierii, lecz dzięki jasnym pytaniom zadanym na etapie przekazania:

• Czy każda wartość w Twoich wymaganiach zawiera jednostkę?
• Czy każdy interfejs między zespołami ma osobę za niego odpowiedzialną?
• Czy jest jasne, która wersja specyfikacji jest aktualna?
• Gdyby jutro coś się zmieniło, czy Twój proces pokazałby, co wymaga przeglądu?

Teraz zadaj sobie te same pytania w odniesieniu do swojego projektu. Jeśli odpowiedź na którekolwiek z nich brzmi „prawdopodobnie”, już wiesz, od czego zacząć.

Dbaj o to, aby ważne informacje inżynieryjne były jasne i łatwe do sprawdzenia na każdym etapie przekazania dzięki narzędziu do zarządzania wymaganiami, z którego może korzystać cały Twój zespół.

Zacznij korzystać z Requirements Portal →

Często zadawane pytania

Dlaczego w projektach inżynieryjnych dochodzi do błędów konwersji jednostek?

Takie pomyłki rzadko wynikają ze złych obliczeń. Pojawiają się na etapach przekazania, gdy wartość przechodzi między zespołami, narzędziami lub dokumentami. Jedna strona może zakładać, że wartość jest wyrażona w jednej jednostce, podczas gdy druga odczytuje ją w innej. Sama wartość nadal może być poprawna, ale jest poprawna dla błędnego założenia.

Co powinna zawierać kompletna wartość wymagania?

Kompletna wartość wymagania powinna zawierać liczbę, jednostkę oraz kontekst potrzebny do jej poprawnego użycia. Na przykład „45” nie wystarczy; „45 milimetrów” już tak. Zespół może też potrzebować wiedzieć, w jakim warunku dana wartość obowiązuje, jaki jest dokument źródłowy i kto jest właścicielem tego wymagania.

Jak śledzalność pomaga ograniczać błędy przy przekazaniach?

Śledzalność łączy wartość ze wszystkim, co od niej zależy: od wymagania najwyższego poziomu aż po część, test i właściciela z nią związanych. Gdy wartość się zmienia, te powiązania ułatwiają znalezienie tego, co jeszcze może wymagać przeglądu. Zmniejsza to ryzyko, że przez pomyłkę nadal będą używane stara specyfikacja, niejasna jednostka albo nieaktualny test.