Zintegrowane projektowanie PCB a przestarzałe narzędzia punktowe: jaki jest rzeczywisty koszt?

W 2016 roku Samsung wycofał Galaxy Note 7 po tym, jak wady konstrukcyjne i produkcyjne baterii doprowadziły do przegrzewania, pożarów i globalnej akcji wycofania produktu. Produkt nie zawiódł dlatego, że akumulatory litowo-jonowe były nowością albo że inżynierom brakowało umiejętności, lecz dlatego, że proces rozwoju produktu dopuścił do tego, by do klientów trafiły zbyt małe marginesy projektowe, słaby zakres walidacji i niekontrolowana zmienność produkcyjna.

W rozwoju PCB ta sama kategoria załamania procesu pojawia się wtedy, gdy dane projektowe są rozproszone między niepołączonymi, wyspecjalizowanymi narzędziami obsługującymi niezależnie od siebie tworzenie schematów, layout, symulację i generowanie danych produkcyjnych. Bez ujednoliconego modelu danych łączącego te etapy błędy, które powinny zostać wychwycone wcześnie, przedostają się do plików produkcyjnych. Rzeczywisty koszt starszych przepływów pracy opartych na odseparowanych narzędziach punktowych to skumulowane ryzyko niespójnych danych, utraconej identyfikowalności i powolnej analizy przyczyn źródłowych wraz ze wzrostem złożoności produktu i wymagań zgodności.

Najważniejsze wnioski

• Starsze przepływy pracy oparte na odseparowanych narzędziach punktowych generują ukryte koszty poprzez przekazywanie pracy między etapami, poprawki, translację plików i opóźnioną informację zwrotną.
• Zintegrowane środowiska projektowe ograniczają przełączanie kontekstu, łącząc projektowanie, współpracę, wymagania, przegląd mechaniczny i dane łańcucha dostaw.
• Rzeczywiste porównanie kosztów dotyczy nie tylko ceny oprogramowania, lecz także czasu inżynierskiego, spójności zespołu i błędów pojawiających się na dalszych etapach.
• Wraz ze wzrostem skali produktów i zespołów rozproszone przepływy pracy stają się trudniejsze w zarządzaniu i droższe w utrzymaniu.

Koszt cyklu życia a koszt licencji

Zespoły inżynierskie często oceniają łańcuchy narzędzi głównie pod kątem kosztu licencji, wysiłku migracyjnego i czasu potrzebnego na szkolenie. To są rzeczywiste koszty, ale jednorazowe lub okresowe. Koszt przepływu pracy w przypadku rozproszonego toolchainu jest ciągły: powraca co tydzień przez cały okres jego użytkowania.

Pełniejsze porównanie kosztów uwzględnia powtarzające się godziny pracy inżynierów poświęcane na synchronizację, przeróbki spowodowane nieaktualnymi lub brakującymi ograniczeniami, cykle przeglądów wydłużone przez niepewność wersji oraz ECO generowane przez informacje, które dotarły zbyt późno, aby zapobiec błędowi projektowemu. W większości zespołów te powtarzające się koszty przekraczają różnicę w kosztach licencji już w pierwszym roku, szczególnie gdy rośnie wielkość zespołu lub złożoność produktu.

Kalkulacja staje się jeszcze mniej korzystna dla rozproszonych toolchainów, gdy produkty przechodzą przez kolejne etapy swojego cyklu życia. Śledzenie rewizji w niepołączonych systemach z czasem się pogarsza. Gdy produkt wraca do odświeżenia po 18 miesiącach albo gdy nowy inżynier przejmuje projekt, koszt odtworzenia kontekstu projektowego z rozproszonych plików, e-maili i arkuszy kalkulacyjnych może przekroczyć koszt pierwotnego wysiłku projektowego dla tego podsystemu.

Punkty graniczne skalowania dla ręcznej koordynacji

Pojedynczy projektant pracujący samodzielnie często może tolerować rozproszony toolchain, ponieważ cały kontekst znajduje się w pamięci jednej osoby. Przepływ pracy załamuje się jednak w przewidywalnych punktach skalowania:

• Dodanie drugiego projektanta do tej samej płytki, co wymaga bieżącej świadomości wzajemnych zmian
• Włączenie właściciela ograniczeń mechanicznych, który potrzebuje dwukierunkowej widoczności środowiska PCB
• Przejście od prototypu do produkcji, gdzie przekazanie do wytwarzania wymaga pełnej i spójnej dokumentacji
• Wymóg formalnych przeglądów projektu z identyfikowalnością między wymaganiami a implementacją
• Obsługa wielu aktywnych projektów jednocześnie, gdzie przełączanie kontekstu między projektami zwielokrotnia narzut synchronizacji

W każdym z tych punktów granicznych obciążenie ręczną koordynacją rośnie nieliniowo. Zespół albo akceptuje ten narzut w postaci niższej przepustowości, albo błędy zaczynają przedostawać się do procesów wytwarzania i montażu.

Typowe tryby awarii w rozproszonych przepływach pracy

Poniższa tabela mapuje konkretne scenariusze awarii na ich przyczynę źródłową i typowy moment wykrycia. Każdy z nich przedstawia przypadek, w którym zintegrowane środowisko z bezpośrednim przepływem ograniczeń albo zapobiegłoby błędowi, albo natychmiast by go ujawniło.

Ocena głębokości integracji

Nie wszystkie zintegrowane środowiska zapewniają ten sam poziom przepływu ograniczeń. Przy ocenie, czy dana platforma rzeczywiście rozwiązuje problem fragmentacji, istotne są następujące pytania:

• Czy ograniczenia mechaniczne (obrys płytki, keepouty, wysokości komponentów) przepływają dwukierunkowo między MCAD i ECAD bez ręcznej wymiany plików?
• Czy decyzje dotyczące BOM i łańcucha dostaw są widoczne w środowisku projektowym, czy wymagają przełączania się do oddzielnego portalu?
• Czy historia rewizji rejestruje kto, co, kiedy i dlaczego zmienił, we wszystkich domenach na jednej osi czasu?
• Czy komentarze do przeglądu projektu mogą być przypinane bezpośrednio do obiektów projektowych, zamiast funkcjonować w oddzielnym dokumencie lub wątku e-mailowym?
• Czy zmiany ograniczeń są automatycznie propagowane do powiązanych reguł, czy trzeba je ręcznie wprowadzać ponownie?

Odpowiedzi decydują o tym, czy platforma eliminuje błędy przekazań między etapami, czy jedynie konsoliduje interfejs użytkownika, pozostawiając nienaruszoną podstawową fragmentację danych.

Ujednolicone przepływy pracy dla złożonego projektowania PCB na dużą skalę

Wraz z rozwojem zespołów i wzrostem złożoności projektów luki między narzędziami punktowymi stają się coraz trudniejsze do opanowania. Altium Agile Teams zostało zaprojektowane z myślą o tym etapie wzrostu, gdy koordynacja, widoczność i powtarzalne przeglądy są równie ważne jak same możliwości projektowe. Zapewnia współdzielone środowisko, w którym spotykają się dane projektowe PCB, kontekst mechaniczny, decyzje BOM i informacje z łańcucha dostaw.

Dzięki Agile Teams interesariusze z obszarów elektryki, mechaniki, produkcji i sourcingu mogą przeglądać ten sam, aktualny kontekst projektu, omawiać zmiany bezpośrednio na miejscu i wcześniej uzgadniać decyzje w procesie. Zamiast polegać na eksportach, arkuszach kalkulacyjnych i komunikacji bocznymi kanałami, zespoły zyskują lepszą widoczność tego, co się zmieniło, dlaczego się zmieniło i jakie będzie to miało konsekwencje na dalszych etapach.

Ograniczając tarcia między narzędziami i ludźmi, Altium Agile Teams pomaga rozwijającym się zespołom sprzętowym spędzać mniej czasu na zarządzaniu przepływem pracy, a więcej na dostarczaniu niezawodnych projektów.

Dowiedz się więcej o Altium Agile Teams i zobacz, jak zintegrowane przepływy pracy mogą ograniczyć tarcia wraz ze skalowaniem Twojego zespołu →

Często zadawane pytania dotyczące przejścia na zintegrowane projektowanie PCB

Nasze narzędzia punktowe są już opłacone. Dlaczego mielibyśmy zmieniać?

Ponieważ cena narzędzi to tylko część kosztu. Jeśli przepływ pracy między narzędziami powoduje powtarzające się opóźnienia, niejasności i konieczność poprawek, to nawet tańszy toolchain może ostatecznie kosztować więcej.

Jak oszacować oszczędności wynikające ze współpracy?

Zacznij od czasu pracy inżynierów. Zmierz, ile godzin Twój zespół poświęca na eksporty, porządkowanie BOM, narzut związany z przeglądami projektu, pętle doprecyzowań, koordynację plików oraz usuwanie problemów spowodowanych zbyt późną widocznością informacji. Te godziny to koszt przepływu pracy, nawet jeśli nie pojawiają się w budżecie na oprogramowanie.

Czy możemy bezpiecznie zmigrować nasze biblioteki?

To zależy od ścieżki migracji i używanych narzędzi, ale właściwe pytanie jest szersze: czy nowe środowisko zachowa ważne dane projektowe, a jednocześnie ograniczy fragmentację w przyszłości? Migrację bibliotek należy ocenić starannie, ale nie powinna ona kończyć rozmowy, zanim nie zostanie zrozumiany całkowity koszt przepływu pracy.

Migracja brzmi jak zbyt duży wysiłek.

Migracja rzeczywiście wymaga pracy. Ale powtarzające się tarcia również. Porównanie nie dotyczy wyboru między wysiłkiem a jego brakiem. Chodzi o wybór między jednorazowym wysiłkiem przejścia a ciągłym obciążeniem przepływu pracy.

Czy stracimy kompatybilność?

Kompatybilność należy oceniać bezpośrednio, a nie zakładać z góry. Rzeczywisty cel to poprawa ciągłości bez zamykania danych projektowych w pułapce i bez utrudniania współpracy w przyszłości.