"세인트 아이브스로 가는 길에 일곱 아내를 둔 남자를 만났네"로 시작하는 수수께끼를 들어본 적이 있을 겁니다. 시가 이어지면서 각 아내는 일곱 자루를, 각 자루에는 일곱 마리의 고양이가 들어 있는 식으로 계속됩니다. 결국 "세인트 아이브스로 가는 사람은 몇 명이었을까?"라는 질문이 나옵니다. 이 수수께끼에 대한 흔한 오해는 질문에 답하려면 모든 항목을 곱해야 해서 엄청난 숫자가 나온다는 것입니다.
Cimetrix는 애플리케이션 개발자가 장비 제어 애플리케이션에 장비 데이터 수집(EDA)/인터페이스 A 표준을 통합하는 데 풍부한 경험을 보유하고 있습니다. 때때로 프로세스 모듈 수가 매우 많고 각 프로세스 모듈에 예외가 다수 존재하는 장비 유형을 접하기도 합니다. EDA Freeze II에서 예외는 예외 정의와 예외 인스턴스로 모두 표현됩니다. 다수의 예외를 포함하는 모델을 생성하기 위한 옵션은 무엇인가요?
좋아요
가장 직접적인 접근 방식은 다음 EDA 장비 모델에서 보여주는 것처럼 예외 인스턴스마다 하나의 예외 정의를 갖는 것입니다:
그러나 이 접근법에서는 각 모듈에 5000개의 예외가 존재할 경우, 200개의 모듈은 100만 개의 예외 인스턴스와 이에 상응하는 100만 개의 예외 정의를 생성하게 됩니다. 이러한 모델을 배포하고 유지 관리하는 데 필요한 시스템 자원은 매우 방대합니다.
더 나은
EDA는 단일 예외 정의를 참조하는 다중 예외 인스턴스를 허용합니다. 다음 모델은 이 접근 방식을 보여줍니다:
이 예시에서 프로세스 모듈에는 10개의 예외 인스턴스가 있지만, 현재 설정된 예외 정의는 단 하나뿐임을 확인할 수 있습니다. 이러한 접근 방식을 적용하면 각 모듈에 5000개의 예외 인스턴스가 존재할 경우, 200개의 모듈로도 여전히 100만 개의 예외 인스턴스가 발생하지만, 예외 정의는 200개(모듈당 하나씩)만 존재하게 됩니다. 이는 상당한 감소이지만 여전히 상당히 많은 수치입니다.
최고
프로세스 모듈이 많고 각 모듈마다 예외가 다수 발생하는 장비의 경우, 모듈당 몇 가지의 고유한 예외만 정의하고 일시적 매개변수(또는 데이터 변수)를 사용하여 문제의 실제 원인을 표시하는 것이 가장 효과적인 접근법입니다. 다음 모델은 이를 구현한 예시를 보여줍니다:
위 모델의 프로세스 모듈에는 단 하나의 예외만 존재합니다. 일시적 매개변수 AlarmCode에는 예외 발생 원인을 유발한 정보가 포함됩니다. 추가 정보(하위 오류 코드, 설명 등)가 필요한 경우 여러 예외 매개변수를 가질 수 있습니다.
EDA 표준은 네 가지 예외 심각도 수준(정보, 경고, 오류, 치명적)을 참조합니다. 각 심각도에 대해 하나의 예외 정의를 생성하고 모듈당 최대 네 개의 예외 인스턴스를 허용할 경우, 200개 모듈로 구성된 모델은 네 개의 예외 정의와 최대 800개의 예외 인스턴스를 가질 수 있습니다.
이 예외 통합 접근 방식은 모델 복잡성과 모델 크기를 줄여 장비 제조사와 공장 모두에게 이점을 제공합니다.
위의 수수께끼에 대한 답은 세인트 아이브스로 가는 사람은 단 한 명, 바로 저였습니다. 상대편에 몇 명의 사람이나 고양이 등이 있었는지 고민할 필요가 없었죠. 그들은 반대 방향으로 가고 있었으니까요! 마찬가지로, EDA(Event Driven Architecture)에서 예외 처리를 통합하면 너무 많은 예외를 처리하려고 시간과 시스템 자원을 낭비할 필요가 없습니다.