Czym jest zintegrowane środowisko projektowe dla elektroniki?

Późne wykrycie ograniczeń mechanicznych jest częstą przyczyną opóźnień harmonogramu i konieczności przeróbek w projektach elektronicznych.

Rozważmy typowy scenariusz: trzy miesiące po rozpoczęciu projektu schemat jest gotowy, a projekt PCB jest w dużej mierze ukończony. Dopiero wtedy klient wspomina, że kilka milimetrów nad płytą główną montowana jest druga płytka PCB — coś, co jego zdaniem było oczywiste na podstawie wcześniejszych zdjęć. Na tym etapie wcześniej wybrane złącza i komponenty okazują się zbyt wysokie, co wymusza ponowny dobór części, które i tak są już trudne do pozyskania ze względu na wymagania napięciowe i prądowe. Kilka tygodni pracy zostaje straconych na rozwiązanie ograniczenia, które nigdy nie zostało formalnie uchwycone.

Tego typu problem nie należy do rzadkości. To przewidywalny skutek rozłączonych przepływów pracy projektowej.

Najważniejsze wnioski

• Zintegrowane środowisko projektowe łączy tworzenie schematów, projektowanie PCB, symulację, współpracę MCAD oraz zarządzanie danymi, dzięki czemu inżynierowie nie muszą przełączać się między niepowiązanymi narzędziami.
• Reguły projektowe i ograniczenia (takie jak prześwit, odstępy i wysokość komponentów) muszą być sprawdzane w czasie rzeczywistym podczas projektowania, a nie dopiero po przekazaniu plików do produkcji.
• Ograniczenia mechaniczne i firmware’owe muszą zostać uwzględnione na początku projektu. Ich wykrycie po doborze komponentów prowadzi do niepotrzebnych przeróbek i opóźnień.

Problem: sześć narzędzi do zbudowania jednej płytki

W wielu zespołach sprzętowych przepływ pracy projektowej jest rozproszony między wiele niepołączonych narzędzi. Definicje pad stacków mogą znajdować się w jednej aplikacji. Symbole schematowe i biblioteki są zarządzane w osobnym narzędziu i często przechowywane w różnych lokalnych lub sieciowych folderach. Projekt PCB powstaje gdzie indziej. Integracja systemowa, analiza integralności sygnału i EMI są zwykle wykonywane w dodatkowych, wyspecjalizowanych aplikacjach. Śledzenie projektu i zarządzanie zadaniami często odbywa się przez narzędzia webowe, które nie zawsze są dostępne, gdy inżynierowie pracują offline.

W rezultacie inżynierowie muszą nauczyć się i utrzymywać biegłość w co najmniej pięciu różnych narzędziach tylko po to, aby przeprowadzić projekt od schematu do gotowej do produkcji płytki PCB.

W małych zespołach taka fragmentacja generuje dodatkowy narzut. Przechodzenie między narzędziami wymaga częstego eksportu i importu plików, przy czym na każdym etapie istnieje ryzyko błędów translacji. Biblioteki i footprinty muszą być umieszczone w określonych strukturach katalogów, aby pozostały użyteczne; źle umieszczony plik może uniemożliwić poprawne przeniesienie komponentu ze schematu do layoutu.

Znaczna ilość czasu jest tracona na wyszukiwanie symboli schematowych, footprintów PCB i właściwych wersji plików — pracy, która powinna być trywialna, ale często pochłania dni lub tygodnie w trakcie projektu.

Pomimo liczby używanych narzędzi końcowa koordynacja nadal opiera się na e-mailach i arkuszach kalkulacyjnych. Same narzędzia pozostają w dużej mierze od siebie odłączone, zapewniając niewielką wspólną widoczność w całym procesie projektowym.

Co naprawdę oznacza zintegrowane środowisko projektowe

Zintegrowane środowisko projektowe dla elektroniki to pojedyncza aplikacja lub ściśle powiązany zestaw narzędzi, który obsługuje cały przepływ pracy związany z projektowaniem sprzętu:

• Tworzenie schematów do projektowania obwodów
• Projekt PCB do rozmieszczania komponentów i trasowania
• Symulacja do walidacji przed produkcją
• Współpraca ECAD-MCAD, dzięki której zespoły elektryczne i mechaniczne pracują na tych samych danych
• Zarządzanie danymi dla bibliotek komponentów, plików projektowych i wymagań projektowych

W zintegrowanym środowisku te same dane bazowe są wykorzystywane na wszystkich etapach projektowania. Zmiany wprowadzone na schemacie są bezpośrednio przenoszone do projektu PCB. Ograniczenia mechaniczne, takie jak obrys płytki czy prześwity obudowy, są widoczne w środowisku projektowania elektrycznego w miarę ich aktualizacji.

Eliminuje to ręczny eksport, import plików i niezgodności wersji, które są powszechne w łańcuchach narzędzi zbudowanych wokół niepołączonych aplikacji.

• Aby uzyskać szczegółowe wyjaśnienie, jak działa to w praktyce między zespołami elektrycznymi i mechanicznymi, zobacz współpracę ECAD-MCAD w Altium Develop.

Jak integracja zamyka pętlę sprzężenia zwrotnego

Oto typowy scenariusz w projekcie elektroniki mocy. Projekt PCB powstaje w jednym narzędziu, schemat jest tworzony w innym, a obudowa jest projektowana osobno w PTC Creo przez inżyniera mechanika. Żadne z tych środowisk nie współdzieli danych projektowych na żywo.

W takim przypadku obudowa ledwo mieściła PCB, a wiązki kablowe naruszały wymagania dotyczące odstępów. Problemy te nie były odosobnionymi błędami projektowymi. Wystąpiły dlatego, że żadne pojedyncze środowisko nie zapewniało wglądu w pełny kontekst mechaniczny i elektryczny. Rozwiązanie konfliktów wymagało wielu iteracji między zespołami elektrycznymi i mechanicznymi oraz dodało od dwóch do trzech tygodni do harmonogramu.

Gdy narzędzia ECAD i MCAD są zintegrowane, ta pętla sprzężenia zwrotnego zostaje zamknięta. Inżynier mechanik definiuje obrys płytki i ograniczenia bezpośrednio na podstawie modelu obudowy, a te ograniczenia są przenoszone do projektu PCB. Inżynier elektryk natychmiast widzi dostępną powierzchnię płytki, zweryfikowane lokalizacje otworów montażowych oraz limity wysokości komponentów, zanim podejmie decyzje dotyczące doboru części lub trasowania.

Taka dwukierunkowa synchronizacja ogranicza liczbę iteracji, zapobiega konfliktom wykrywanym na późnym etapie i skraca cały cykl projektowy.

• Aby uzyskać dodatkowe informacje na temat współpracy ECAD-MCAD, zobacz dokumentację MCAD CoDesigner.

Walidacja reguł projektowych w czasie rzeczywistym ratuje Twoje płytki

Via ścieżek powrotnych, naruszenia prześwitów oraz błędy odstępów związane z projektowaniem pod kątem produkcji lub montażu są częstymi przyczynami przeróbek PCB i ponownych rewizji. Problemy te często pozostają niewykryte, gdy reguły projektowe są sprawdzane dopiero po zakończeniu layoutu.

Walidacja reguł projektowych w czasie rzeczywistym sygnalizuje naruszenia w momencie ich wprowadzenia. Jeśli ograniczenie prześwitu zostanie naruszone, jest to natychmiast widoczne. Jeśli szerokość ścieżki nie spełnia wymagań przypisanej klasy sieci, błąd jest podświetlany bezpośrednio w layoucie.

To podejście różni się od wsadowego sprawdzania reguł projektowych, które identyfikuje problemy dopiero po zakończeniu prac projektowych. Kontrole wsadowe ujawniają problemy, które mogły zostać wprowadzone godziny lub dni wcześniej. Sprawdzanie w czasie rzeczywistym zapobiega rozprzestrzenianiu się tych błędów poprzez egzekwowanie ograniczeń podczas tworzenia layoutu.

• Dowiedz się więcej o sprawdzaniu reguł projektowych w Altium Develop.

Prawdziwy koszt „działa dobrze”

„Nasz obecny łańcuch narzędzi działa dobrze” często oznacza, że proces jest kruchy.

W jednym z projektów oprogramowanie do tworzenia schematów było używane do projektowania kabli i wiązek przewodów. Choć było to technicznie możliwe, narzędzie nie zostało zaprojektowane do tego celu. W rezultacie zmiany elektryczne nie były automatycznie przenoszone do rysunków, a każda etykieta i każde pole tekstowe musiały być aktualizowane ręcznie.

Prowadziło to do przewidywalnych błędów. Kilka wiązek kablowych zostało wykonanych z nieprawidłowym okablowaniem, ponieważ dokumentacja nie była zsynchronizowana z rzeczywistym projektem. Inżynierowie poświęcali znaczną ilość czasu na przegląd, ponowne sprawdzanie i korygowanie błędów, którym samo narzędzie powinno było zapobiec. Indywidualna produktywność spadła szacunkowo do 40–50% z powodu stałego narzutu związanego z ręcznymi aktualizacjami i weryfikacją.

System działał, ale tylko w tym sensie, że nie zawiódł natychmiast. Prawdziwy koszt „działa dobrze” był płacony w postaci przeróbek, opóźnień i zmniejszonej wydajności inżynierskiej.

Gdy firmware i mechanika pojawiają się zbyt późno

W niedawnym projekcie główny projekt PCB został ukończony, lista materiałowa sfinalizowana, a projekt był gotowy do przekazania do produkcji.

W tym momencie pojawiło się nowe ograniczenie: na głównej płytce miała zostać zamontowana dodatkowa płytka LED, przy zaledwie 10 mm prześwitu w pionie.

To późne wymaganie wymusiło przeprojektowanie dotkniętego obszaru. Istniejące złącza przekraczały dopuszczalną wysokość. Komponenty o wystarczającej obciążalności prądowej nie były dostępne w niskoprofilowych obudowach. Alternatywne części spełniające wymaganie wysokości miały niepraktyczne minimalne wielkości zamówienia albo były już wycofane z produkcji.

Na ocenę alternatyw poświęcono około czterech tygodni, co wygenerowało dodatkowe koszty konsultingowe w wysokości 2000 USD (około 10% całkowitego budżetu projektu), tylko po to, by stwierdzić, że pierwotne podejście projektowe nie było wykonalne.

Dodatkowo przestoje związane z obchodami Chińskiego Nowego Roku opóźniły produkcję. Płytki, które powinny były zostać wysłane w październiku lub listopadzie, dostarczono dopiero w marcu.

Przyczyną źródłową nie była awaria techniczna, lecz porażka procesu. Ograniczenia mechaniczne nie zostały zakomunikowane na początku projektu i nie istniało wspólne środowisko, w którym zespoły elektryczne, mechaniczne i firmware’owe mogłyby wcześnie w cyklu projektowym przeglądać i weryfikować wymagania na poziomie systemu.

Dlaczego wszystko musi ze sobą współpracować

Systemy programowe często mogą tolerować częściową awarię. Jeśli jedna funkcja przestaje działać, inne części aplikacji mogą nadal działać, co pozwala naprawiać problemy stopniowo.

Systemy sprzętowe tak nie działają.

Jeśli architektura zasilania jest nieprawidłowa, jeśli translatory poziomów zostały źle zastosowane lub jeśli zawodzą podstawowe interfejsy, duże części płytki nie będą działać albo system w ogóle się nie uruchomi. Sprzęt wymaga wysokiego poziomu poprawności we wszystkich podsystemach, zanim będzie można rozpocząć sensowne testy.

Ponieważ sprzęt jest z natury zintegrowany, proces rozwoju również musi być zintegrowany. Wymagania nie mogą istnieć wyłącznie w wątkach e-mailowych. Reguły projektowe nie mogą być sprawdzane dopiero na końcu procesu layoutu. Ograniczenia mechaniczne nie mogą być odkrywane po wielu miesiącach prac rozwojowych bez wprowadzania przeróbek i opóźnień.

Narzędzia projektowe powinny odzwierciedlać tę rzeczywistość. Dane elektryczne, mechaniczne i komponentowe muszą być połączone, widoczne i dostępne przez cały cykl projektowy, a nie zarządzane jako rozłączne pliki i przekazania między zespołami.

Dla zespołów gotowych wyjść poza rozłączony łańcuch narzędzi Altium Develop jest dobrym punktem wyjścia. 

Niezależnie od tego, czy chcesz tworzyć niezawodną elektronikę mocy, czy zaawansowane systemy cyfrowe, Altium Develop łączy wszystkie dyscypliny w jedną współpracującą siłę. Bez silosów. Bez ograniczeń. To miejsce, w którym inżynierowie, projektanci i innowatorzy pracują jako jeden zespół, współtworząc bez ograniczeń. Poznaj Altium Develop już dziś!

Często zadawane pytania

Czym jest zintegrowane środowisko projektowe dla elektroniki?

Zintegrowane środowisko projektowe łączy tworzenie schematów, projektowanie PCB, symulację, współpracę ECAD-MCAD oraz zarządzanie danymi w jeden spójny, połączony przepływ pracy. Zamiast przenosić pliki między oddzielnymi narzędziami, inżynierowie pracują na współdzielonych danych, dzięki czemu zmiany są automatycznie propagowane między etapami projektowania.

W jaki sposób zintegrowane środowisko ogranicza przeróbki i opóźnienia harmonogramu?

Dzięki walidacji ograniczeń elektrycznych, mechanicznych i produkcyjnych w czasie rzeczywistym problemy takie jak naruszenia prześwitów, limity wysokości komponentów czy konflikty trasowania są wykrywane w momencie ich wystąpienia, a nie tygodnie później. Zapobiega to przeprojektowaniom na późnym etapie, które zwykle powodują opóźnienia i dodatkowe koszty.

Dlaczego integracja ECAD-MCAD jest tak ważna na wczesnym etapie projektu?

Ograniczenia mechaniczne, takie jak geometria obudowy, układanie płytek w stosie oraz wyrównanie złączy, bezpośrednio wpływają na dobór komponentów i decyzje dotyczące rozmieszczenia elementów. Gdy ograniczenia te są widoczne od samego początku, zespoły unikają wyboru części lub architektur, które później okazują się niewykonalne.

Czym kontrola reguł projektowych w czasie rzeczywistym różni się od tradycyjnych kontroli wsadowych?

Kontrola w czasie rzeczywistym natychmiast sygnalizuje błędy po naruszeniu reguły, dzięki czemu inżynierowie mogą korygować problemy, zanim się rozprzestrzenią. Kontrole wsadowe identyfikują problemy dopiero po zakończeniu projektowania układu, co często wymaga znacznego cofania zmian i przeróbek.