Stołowe stanowisko inspekcyjne AOI SI-V100 firmy Sony
System automatycznej kontroli optycznej (AOI) potencjalnie zapewnia solidne metody kontroli procesu, gdyż może zidentyfikować jego zagadnienia w sposób spójny i bezstronny. Jednym z głównych problemów jest zapewnienie krótkiego czasu opracowania nowego programu, obniżającego koszty i skracającego czas jego wdrożenia. Drugim ważnym zagadnieniem jest poprawność programu, eliminująca potrzebę wykrywania i usuwania błędów. Wszyscy dostawcy AOI dążą do tworzenia dobrych programów w coraz krótszym czasie.
W wielu ocenach jedynie początkowy czas programowania jest używany do określania kosztów programowania dla systemu. Jednak czy takie podejście jest wystarczające dla odzwierciedlenia całkowitego czasu programowania i kosztów? Czy program szybko wygenerowany daje bardzo wysoki poziom wiarygodności testu? Odpowiedź brzmi: nie. Poniżej podano przykład tego, co zdarza się w rzeczywistości. Zaznaczmy, że taka sytuacja nie występuje w systemach AOI produkowanych przez Sony.
Próbka użyta do oceny ma 500 punktów testowych. Na testowanym AOI program jest wdrożony, użyty do testu i przechodzi pozytywnie w 100%. Aby szybko zweryfikować brak błędów, usuwa się zmontowane płytki PCB i zastępuje takimi samymi nie zmontowanymi, a program jest uruchamiany ponownie. Oczywiście można się spodziewać, że bez elementów i lutów system pokaże 100% błędów. Ale w tym przypadku system AOI przechodzi prawie 30 kroków testowych i około 6% z nich to błędy.
Po tym przykładzie nasuwa się kilka pytań:
- Czy program pokazujący 100% pozytywnych wyników jest rzeczywiście poprawny?
- Jeśli program z błędami jest wdrażany do produkcji, ile czasu potrzeba na poprawki?
- Jak długo będzie trwało sprawdzanie błędnych wyników?
- Ile czasu zostanie stracone na linii produkcyjnej?
- Jak niezawodny i powtarzalny jest ten system AOI przy sprawdzaniu dopuszczalnych odchyleń w ramach procesu?
Właściwszą metodą pomiaru czasu programowania i kosztów przy ocenie systemu AOI jest uwzględnienie całego wysiłku potrzebnego do opracowania programu początkowego, wykrywania i usuwania błędów oraz strat tym spowodowanych. Jest to właśnie całkowity nakład wprowadzania programu, a zatem całkowity koszt programowania.
Kiedy pomnożymy ten koszt przez liczbę produktów, które będą programowane w przyszłości staje się oczywiste, że używając tylko czasu początkowego do zdefiniowania czasu programowania, koszty te mogą poważnie zaniżać prawdziwy czas i koszt tworzenia programu Szybkie tworzenie programu często wydaje się być najbardziej efektywną drogą.
Z drugiej strony, może lepszy jest system wymagający więcej czasu na tworzenie początkowego programu testowego, który będzie jednak solidny i wolny od błędów. Ta opcja wydaje się bardziej opłacalna ze względu na mniejsze koszty związane ze zużyciem płytek, komponentów oraz czasu straconego na poprawianie programu.
Artur Oporski
Ambex
www.ambex.pl
