Własne kontrole i walidacje

Standard design rules cover geometry and electrical correctness. Custom checks cover everything else – your company's standards, your industry's requirements, and your organization's institutional knowledge.

Framework Behavior Extensibility firmy Altium umożliwia pisanie własnej logiki walidacji w Pythonie i podłączanie jej do punktów kontrolnych platformy w całym cyklu życia projektu: ERC i DRC w Altium Designer, walidacji BOM i komponentów, bramek zatwierdzających wydanie, etapów przeglądu projektu oraz kroków workflow na serwerze. Własne kontrole są wyświetlane i działają identycznie jak wbudowane kontrole platformy – ten sam interfejs użytkownika, ten sam panel błędów, to samo cross-probe do danego komponentu lub sieci.

Kontrole nie są ograniczone wyłącznie do danych Altium. Kontrola może odwoływać się do wewnętrznej bazy części, listy zatwierdzonych dostawców, systemu ERP lub dowolnego zewnętrznego źródła danych, od którego zależy pipeline walidacji. Wynik jest zwracany i prezentowany w Altium Designer dokładnie tak samo jak wynik natywnej kontroli.

Do czego naprawdę służą Custom Checks

Większość organizacji odkrywa potrzebę stosowania własnych kontroli, gdy napotyka klasę problemów, która stale się powtarza mimo przechodzenia istniejących reguł DRC. Typowe przykłady:

• Voltage derating rules – specyficzne dla rodziny produktów lub segmentu branży. Kondensatory na liniach niskiego napięcia, kondensatory elektrolityczne w pobliżu źródeł ciepła

• Component qualification gates – części od niezatwierdzonych producentów, komponenty objęte kontrolą ITAR, części wycofane z produkcji, które zostały oznaczone przez dział zakupów

• BOM completeness rules – wymagane parametry nieuzupełnione, brak zatwierdzonych zamienników, niekompletne dane producenta

• Release documentation requirements – określone pliki wyjściowe, które muszą istnieć i być aktualne, aby wydanie było ważne

• Organizational standards – zasady istniejące wyłącznie w wiedzy nieformalnej, egzekwowane niespójnie przez osobę przeglądającą projekt

Własne kontrole przenoszą takie kwestie z etapu przeglądu – zależnego od dostępności odpowiedniej osoby i od tego, czy pamięta, żeby to sprawdzić – do zautomatyzowanej bramki uruchamianej za każdym razem.

Wartość kodowania wiedzy w kontrolach

Gdy starszy inżynier tworzy własną kontrolę, dzieją się dwie rzeczy. Kontrola uruchamia się automatycznie dla każdego kolejnego projektu, niezależnie od tego, kto go stworzył. A gdy ten inżynier odchodzi, wiedza pozostaje. To właśnie ta właściwość ma największe znaczenie przy skali: wiedza instytucjonalna przestaje być zakładnikiem liczby pracowników.

Nowi inżynierowie w zespole automatycznie korzystają z kontroli napisanych przez inżynierów z wieloletnim doświadczeniem domenowym. Reguła nie wymaga wyjaśnień ani przeglądu – po prostu działa.

Co sprawdzać, a czego nie sprawdzać

Własne kontrole dobrze sprawdzają się w deterministycznej walidacji opartej na regułach: warunkach, które dla określonego stanu projektu są zawsze prawdziwe albo zawsze fałszywe. Nie zastępują eksperckiego przeglądu projektu, symulacji ani oceny opartej na osądzie.

Dobrym kandydatem na własną kontrolę jest każda reguła, którą można wyrazić w formie: „oznacz ten komponent / tę sieć / ten parametr, jeśli warunek X jest spełniony”. Słabym kandydatem jest wszystko, co wymaga zrozumienia kontekstu, interpretacji intencji projektowej lub oceny kompromisów. To nadal wymaga przeglądu przez człowieka. Własne kontrole stanowią zautomatyzowaną podstawę, która wychwytuje wszystko, co może wychwycić maszyna, tak aby czas przeglądu wykonywanego przez człowieka był poświęcany na rzeczy, które tylko człowiek może wychwycić.

Podejścia, które nie skalują się

• Manual pre-release checklists – sprawdzają się w małych zespołach z rzadkimi wydaniami. Przestają działać, gdy zespół rośnie, tempo wydań wzrasta albo osoba utrzymująca checklistę jest niedostępna. Checklisty są też niewidoczne dla inżyniera podczas projektowania – informacja zwrotna pojawia się zbyt późno, by naprawa była tania.

• Review-only enforcement – poleganie na osobach przeglądających projekt, by wychwytywały standardowe naruszenia, oznacza, że te same błędy są wielokrotnie wykrywane przez te same osoby. Pochłania to czas ekspertów na problemy deterministyczne, pozostawia wcześniejsze etapy projektu bez ochrony i prowadzi do niespójnego egzekwowania zasad przez różnych recenzentów.