동적 시뮬레이션 과정에서 TOR 요구 사항의 자동 검증

테마 계속하기 "당신의 증거는 무엇입니까?", 다른 측면에서 수학적 모델링의 문제를 살펴 보겠습니다. 모델이 일상적인 삶의 진실과 일치한다고 확신한 후에는 "여기에 정확히 무엇이 있습니까?"라는 주요 질문에 답할 수 있습니다. 기술 개체의 모델을 생성할 때 일반적으로 우리는 이 개체가 우리의 기대를 충족하는지 확인하려고 합니다. 이를 위해 프로세스의 동적 계산이 수행되고 그 결과가 요구 사항과 비교됩니다. 디지털 트윈, 가상 프로토타입 등이 그것이다. 디자인 단계에서 우리가 계획한 것을 어떻게 얻을 수 있는지에 대한 문제를 해결하는 패셔너블한 작은 사람들입니다.

우리 시스템이 우리가 설계한 것과 정확히 일치하는지, 우리의 설계가 날아갈 것인지 아니면 떠 다닐 것인지 어떻게 신속하게 확인할 수 있습니까? 만약 날아간다면 얼마나 높이 올라갈까요? 그리고 그것이 떠 있다면 얼마나 깊을까요?

이 기사에서는 기술 시스템의 동적 모델을 생성할 때 기술 건물의 요구 사항 준수 여부를 확인하는 자동화에 대해 설명합니다. 예를 들어 항공기 공기 냉각 시스템의 기술 사양 요소를 살펴보겠습니다.

우리는 특정 계산 모델을 기반으로 수치적으로 표현되고 수학적으로 검증될 수 있는 요구 사항을 고려합니다. 이는 모든 기술 시스템에 대한 일반적인 요구 사항의 일부일 뿐이라는 것은 분명하지만, 물체의 동적 모델을 만드는 데 시간, 신경 및 돈을 소비하는 것은 이를 확인하는 것입니다.

문서 형식으로 기술 요구 사항을 설명할 때 여러 유형의 서로 다른 요구 사항을 구분할 수 있으며, 각 요구 사항은 요구 사항 이행의 자동 검증을 형성하기 위해 서로 다른 접근 방식이 필요합니다.

예를 들어, 다음과 같은 작지만 현실적인 요구 사항을 고려해보세요.

1. 수처리 시스템 입구의 대기 온도:
   주차장에서 - 영하 35에서 35 ºС,
   비행 중 - 영하 35도에서 39도까지.
2. 비행 중 대기의 정압은 700~1013GPa(526~760mmHg)입니다.
3. 비행 중 SVO 공기 흡입구 입구의 총 기압은 754~1200GPa(566~1050mmHg)입니다.
4. 냉각 공기 온도:
   주차장에서 - 27 ºС 이하, 기술 블록의 경우 - 29 ºС 이하,
   비행 중 - 25 ºС 이하, 기술 블록의 경우 - 27 ºС 이하.
5. 냉각 공기 흐름:
   주차 시 - 최소 708kg/h,
   비행 중 - 660kg/h 이상.
6. 계기실의 공기 온도는 60 ºС 이하입니다.
7. 냉각 공기에 포함된 미세한 자유 수분의 양은 건조한 공기의 2g/kg을 넘지 않습니다.

이 제한된 요구 사항 내에서도 시스템에서 다르게 처리해야 하는 범주가 최소한 두 개 이상 있습니다.

• 시스템 작동 조건에 대한 요구 사항(1-3항)
• 시스템에 대한 매개변수적 요구사항(3-7절)

시스템 작동 조건 요구 사항
모델링 중에 개발되는 시스템의 외부 조건은 경계 조건으로 지정되거나 일반 시스템의 작동 결과로 지정될 수 있습니다.
동적 시뮬레이션에서는 지정된 작동 조건이 시뮬레이션 프로세스에 포함되는지 확인해야 합니다.

파라메트릭 시스템 요구 사항
이러한 요구사항은 시스템 자체에서 제공하는 매개변수입니다. 모델링 프로세스 중에 이러한 매개변수를 계산 결과로 얻을 수 있으며 각 특정 계산에서 요구 사항이 충족되는지 확인할 수 있습니다.

요구 사항 식별 및 코딩

요구 사항을 쉽게 처리할 수 있도록 기존 표준에서는 각 요구 사항에 식별자를 할당하는 것을 권장합니다. 식별자를 할당할 때 통합 코딩 시스템을 사용하는 것이 매우 바람직합니다.

요구사항 코드는 단순히 요구사항의 주문 번호를 나타내는 숫자일 수도 있고, 요구사항 유형에 대한 코드, 적용되는 시스템 또는 장치에 대한 코드, 매개변수 코드, 위치 코드 및 기타 사항을 포함할 수도 있습니다. 엔지니어가 상상할 수 있는 모든 것. (인코딩 사용에 대한 기사 참조)

표 1은 요구사항 코딩의 간단한 예를 제공합니다.

1. 요구사항 R-요구사항 TK의 소스 코드;
2. 코드 요구사항 유형 E - 요구사항 - 환경 매개변수 또는 작동 조건
   S - 시스템에서 제공하는 요구 사항
3. 항공기 상태 코드 0 – 모두, G – 주차됨, F – 비행 중;
4. 물리적 매개변수 유형 코드 T – 온도, P – 압력, G – 유량, 습도 H;
5. 요구 사항의 일련 번호입니다.

ID 요구 사항	기술	매개 변수
REGT01	수냉 시스템 입구의 주변 온도: 주차장 - 영하 35°С. 최대 35ºС.
REFT01	방공 시스템 입구의 대기 온도 : 비행 중 - 영하 35 ºС ~ 39 ºС.
REFP01	비행 중 정적 대기압은 700~1013hPa(526~760mmHg)입니다.
REFP02	비행 중 SVO 공기 흡입구 입구의 총 기압은 754~1200hPa(566~1050mmHg)입니다.
RSGT01	냉각 공기 온도 : 주차시 27 ºС 이하
RSGT02	냉각 공기 온도 : 주차장에서 기술 장치의 경우 29 ºС 이하
RSFT01	비행 중 냉각 공기 온도는 25 ºС 이하입니다.
RSFT02	냉각 공기 온도: 비행 중, 기술 장치의 경우 27ºС 이하
RSGG01	냉각 공기 흐름: 주차 시 708kg/h 이상
RSFG01	냉각 공기 흐름: 비행 중 660kg/h 이상
RS0T01	기기 구획의 공기 온도는 60 ºС 이하입니다.
RSH01	냉각 공기에 포함된 미세한 자유 수분의 양은 건조한 공기의 2g/kg을 넘지 않습니다.

요구사항 검증 시스템 설계.

각 설계 요구사항에는 설계 매개변수와 요구사항에 지정된 매개변수의 일치성을 평가하기 위한 알고리즘이 있습니다. 전반적으로 모든 제어 시스템에는 항상 기본적으로 요구 사항을 확인하는 알고리즘이 포함되어 있습니다. 심지어 모든 규제 기관에도 이러한 요소가 포함되어 있습니다. 온도가 한계를 벗어나면 에어컨이 켜집니다. 따라서 모든 규제의 첫 번째 단계는 매개변수가 요구 사항을 충족하는지 확인하는 것입니다.

검증은 알고리즘이므로 제어 프로그램을 만드는 데 사용하는 것과 동일한 도구와 도구를 사용할 수 있습니다. 예를 들어, SimInTech 환경을 사용하면 모델의 다양한 부분을 포함하는 프로젝트 패키지를 생성하여 별도의 프로젝트(객체 모델, 제어 시스템 모델, 환경 모델 등) 형태로 실행될 수 있습니다.

이 경우 요구사항 검증 프로젝트는 동일한 알고리즘 프로젝트가 되어 모델 패키지에 연결됩니다. 그리고 동적 모델링 모드에서는 기술 사양의 요구 사항을 준수하는지 분석을 수행합니다.

시스템 설계의 가능한 예가 그림 1에 나와 있습니다.

그림 1. 검증 프로젝트 설계의 예.

제어 알고리즘과 마찬가지로 요구 사항은 시트 세트로 작성될 수 있습니다. SimInTech, Simulink, AmeSim과 같은 구조 모델링 환경에서 알고리즘 작업의 편의를 위해 하위 모델 형태로 다단계 구조를 생성하는 기능이 사용됩니다. 이 조직을 사용하면 제어 알고리즘에서 수행되는 것처럼 다양한 요구 사항을 세트로 그룹화하여 일련의 요구 사항에 대한 작업을 단순화할 수 있습니다(그림 2 참조).

그림 2. 요구사항 검증 모델의 계층적 구조.

예를 들어, 고려 중인 경우 환경에 대한 요구 사항과 시스템에 대한 직접 요구 사항이라는 두 그룹이 구별됩니다. 따라서 두 가지 수준의 데이터 구조, 즉 두 그룹이 사용되며 각 그룹은 알고리즘의 리프입니다.

데이터를 모델에 연결하기 위해 프로젝트 부분 간 교환을 위한 데이터를 저장하는 신호 데이터베이스 생성을 위한 표준 체계가 사용됩니다.

소프트웨어를 만들고 테스트할 때 제어 시스템에서 사용하는 센서(실제 시스템 센서의 아날로그) 판독값이 이 데이터베이스에 저장됩니다.
테스트 프로젝트의 경우 동적 모델에서 계산된 모든 매개변수를 동일한 데이터베이스에 저장할 수 있으므로 요구 사항이 충족되는지 확인하는 데 사용할 수 있습니다.

이 경우 동적 모델 자체는 모든 수학적 모델링 시스템이나 실행 가능한 프로그램의 형태로 실행될 수 있습니다. 유일한 요구 사항은 모델링 데이터를 외부 환경에 발행하기 위한 소프트웨어 인터페이스가 있다는 것입니다.

그림 3. 검증 프로젝트를 복잡한 모델에 연결합니다.

기본 요구사항 검증 시트의 예가 그림 4에 나와 있습니다. 개발자의 관점에서는 요구사항 검증 알고리즘을 그래픽으로 표현한 일반적인 계산 다이어그램입니다.

그림 4. 요구사항 체크 시트.

점검 시트의 주요 부분은 그림 5에 설명되어 있습니다. 점검 알고리즘은 제어 알고리즘의 설계 다이어그램과 유사하게 구성됩니다. 오른쪽에는 데이터베이스에서 신호를 읽는 블록이 있습니다. 이 블록은 시뮬레이션 중에 신호 데이터베이스에 액세스합니다.

수신된 신호를 분석하여 요구사항 검증 조건을 계산합니다. 이 경우 항공기의 위치(주차 상태인지 비행 중인지)를 결정하기 위해 고도 분석이 수행됩니다. 이를 위해 모델의 다른 신호와 계산된 매개변수를 사용할 수 있습니다.

확인 중인 검증 조건 및 매개변수는 표준 검증 블록으로 전송되며, 여기서 이러한 매개변수는 지정된 요구사항을 준수하는지 분석됩니다. 결과는 체크리스트를 자동으로 생성하는 데 사용할 수 있는 방식으로 신호 데이터베이스에 기록됩니다.

그림 5. 요구사항 검증 계산 시트의 구조.

테스트할 매개변수는 시뮬레이션 프로세스 중에 계산된 매개변수에 의해 제어되는 데이터베이스에 포함된 신호를 반드시 사용할 필요는 없습니다. 검증 조건을 계산하는 것처럼 초안 요구 사항의 틀 내에서 추가 계산을 수행하는 것을 방해하는 것은 없습니다.

예를 들어 다음 요구 사항은 다음과 같습니다.

목표물까지 비행하는 동안 수정 시스템의 활성화 횟수는 5회를 초과해서는 안 되며, 수정 시스템의 총 작동 시간은 30초를 초과해서는 안 됩니다.

이 경우 시작 횟수와 총 작동 시간을 계산하는 알고리즘이 요구 사항의 설계 다이어그램에 추가됩니다.

일반적인 요구사항 검증 블록.

각 표준 요구 사항 확인란은 특정 유형의 요구 사항 충족 여부를 계산하도록 설계되었습니다. 예를 들어, 환경 요구 사항에는 주차 및 비행 중 주변 작동 온도 범위가 포함됩니다. 이 블록은 모델의 공기 온도를 매개변수로 수신하고 이 매개변수가 지정된 온도 범위를 포괄하는지 여부를 결정해야 합니다./p>

블록에는 param과 Condition이라는 두 개의 입력 포트가 포함되어 있습니다.

첫 번째 항목에는 검사 중인 매개변수가 제공됩니다. 이 경우에는 "외부 온도"입니다.

두 번째 포트에는 부울 변수(검사 수행 조건)가 제공됩니다.

두 번째 입력에서 TRUE(1)가 수신되면 블록은 요구 사항 확인 계산을 수행합니다.

두 번째 입력이 FALSE(0)를 수신하면 테스트 조건이 충족되지 않은 것입니다. 이는 계산 조건을 고려하는 데 필요합니다. 우리의 경우 이 입력은 모델 상태에 따라 검사를 활성화하거나 비활성화하는 데 사용됩니다. 시뮬레이션 중에 항공기가 지상에 있는 경우 비행과 관련된 요구 사항이 확인되지 않으며, 그 반대의 경우도 마찬가지입니다. 항공기가 비행 중인 경우 스탠드에서의 작동과 관련된 요구 사항이 확인되지 않습니다.

이 입력은 모델을 설정할 때(예: 계산 초기 단계)에도 사용할 수 있습니다. 모델이 필요한 상태가 되면 체크 블록이 비활성화되지만 시스템이 필요한 작동 모드에 도달하자마자 체크 블록이 켜집니다.

이 블록의 매개변수는 다음과 같습니다.

• 경계 조건: 확인해야 하는 상한(UpLimit) 및 하한(DownLimit) 범위 제한;
• 경계 범위(TimeInterval)에서 필요한 시스템 노출 시간(초)
• 요청 ID ReqName;
• Out_range 범위 초과 허용은 확인된 범위를 초과하는 값이 요구 사항을 위반하는지 여부를 결정하는 부울 변수입니다.

경우에 따라 테스트 값 출력은 시스템에 약간의 여유가 있고 작동 범위를 벗어나 작동 중일 수 있음을 나타냅니다. 다른 경우, 출력은 시스템이 범위 내에서 설정점을 유지할 수 없음을 의미합니다.

그림 6. 다이어그램의 일반적인 속성 검사 블록과 해당 매개변수.

이 블록을 계산한 결과 출력에 다음 값을 갖는 Result 변수가 형성됩니다.

• 0 – r없음, 값이 정의되지 않았습니다.
• 1 – rDone, 요구 사항이 충족되었습니다.
• 2 – rFault, 요구 사항이 충족되지 않습니다.

블록 이미지에는 다음이 포함됩니다.

• 식별자 텍스트;
• 측정 한계 매개변수의 디지털 디스플레이;
• 매개변수 상태의 색상 식별자입니다.

블록 내부에는 다소 복잡한 논리적 추론 회로가 있을 수 있습니다.

예를 들어, 그림 6에 표시된 장치의 작동 온도 범위를 확인하기 위해 내부 회로가 그림 7에 나와 있습니다.

그림 7. 온도 범위 결정 장치의 내부 다이어그램.

회로 블록 내에서는 블록 매개변수에 지정된 속성이 사용됩니다.
요구 사항 준수 분석 외에도 블록의 내부 다이어그램에는 시뮬레이션 결과를 표시하는 데 필요한 그래프가 포함되어 있습니다. 이 그래프는 계산 중에 확인하거나 계산 후 결과를 분석하는 데 모두 사용할 수 있습니다.

계산 결과는 블록의 출력으로 전송되는 동시에 전체 프로젝트의 결과를 기반으로 생성되는 일반 보고서 파일에 기록됩니다. (그림 8 참조)

시뮬레이션 결과를 바탕으로 생성된 보고서의 예로는 주어진 형식에 따라 생성된 html 파일이 있습니다. 형식은 특정 기관에서 허용하는 형식으로 임의로 구성할 수 있습니다.

회로 블록 내에서는 블록 매개변수에 지정된 속성이 사용됩니다.
요구 사항 준수 분석 외에도 블록의 내부 다이어그램에는 시뮬레이션 결과를 표시하는 데 필요한 그래프가 포함되어 있습니다. 이 그래프는 계산 중에 확인하거나 계산 후 결과를 분석하는 데 모두 사용할 수 있습니다.

계산 결과는 블록의 출력으로 전송되는 동시에 전체 프로젝트의 결과를 기반으로 생성되는 일반 보고서 파일에 기록됩니다. (그림 8 참조)

시뮬레이션 결과를 바탕으로 생성된 보고서의 예로는 주어진 형식에 따라 생성된 html 파일이 있습니다. 형식은 특정 기관에서 허용하는 형식으로 임의로 구성할 수 있습니다.

그림 8. 시뮬레이션 결과를 기반으로 한 보고서 파일의 예.

이 예에서 보고서 양식은 프로젝트 속성에서 직접 구성되었으며 테이블의 형식은 글로벌 프로젝트 신호로 설정되었습니다. 이 경우 SimInTech 자체에서 보고서 설정 문제를 해결하고 결과를 파일에 쓰는 블록은 이러한 줄을 사용하여 보고서 파일에 씁니다.

그림 9. 글로벌 프로젝트 신호에서 보고서 형식 설정

요구 사항에 대한 신호 데이터베이스를 사용합니다.

속성 설정 작업을 자동화하기 위해 각 일반 블록에 대한 신호 데이터베이스에 표준 구조가 생성됩니다. (그림 10 참조)

그림 10. 신호 데이터베이스의 요구사항 확인 블록 구조의 예.

신호 데이터베이스는 다음을 제공합니다.

• 필요한 모든 시스템 요구사항 매개변수를 저장합니다.
• 지정된 매개변수와 현재 모델링 결과를 통해 기존 프로젝트 요구 사항을 편리하게 볼 수 있습니다.
• 스크립팅 프로그래밍 언어를 사용하여 하나의 블록 또는 블록 그룹을 설정합니다. 신호 데이터베이스가 변경되면 다이어그램의 블록 속성 값이 변경됩니다.
• 요구 사항 관리 시스템에 텍스트 설명, 기술 사양 항목에 대한 링크 또는 식별자를 저장합니다.

요구 사항에 대한 신호 데이터베이스 구조는 타사 요구 사항 관리 시스템과 함께 작동하도록 쉽게 구성할 수 있습니다. 요구 사항 관리 시스템과의 상호 작용에 대한 일반적인 다이어그램은 그림 11에 나와 있습니다.

그림 11. 요구사항 관리 시스템과의 상호작용 다이어그램

SimInTech 테스트 프로젝트와 요구 사항 제어 시스템 간의 상호 작용 순서는 다음과 같습니다.

1. 참조 조건은 요구 사항으로 분류됩니다.
2. 기술 사양의 요구 사항은 기술 프로세스의 수학적 모델링을 통해 검증할 수 있도록 식별됩니다.
3. 선택한 요구 사항의 속성은 표준 블록 구조(예: 최대 및 최소 온도)의 SimInTech 신호 데이터베이스로 전송됩니다.
4. 계산 과정에서 구조 데이터는 블록 설계 다이어그램으로 전송되고 분석이 수행되며 결과는 신호 데이터베이스에 저장됩니다.
5. 계산이 완료되면 분석 결과가 요구사항 관리 시스템으로 전송됩니다.

설계 및/또는 요구 사항이 변경되고 변경 사항의 영향을 다시 테스트해야 하는 경우 설계 프로세스 중에 요구 사항 3~5단계가 반복될 수 있습니다.

결론.

• 시스템의 프로토타입이 생성되면 기술 사양 요구 사항을 준수하기 위해 기존 모델을 분석하는 시간이 크게 단축됩니다.
• 제안된 테스트 기술은 기존의 동적 모델을 사용하며 SimInTech 환경에서 수행되지 않는 동적 모델을 포함한 모든 동적 모델에도 사용할 수 있습니다.
• 배치 데이터 구성을 사용하면 모델 개발과 동시에 요구사항 검증 패키지를 생성하거나 이러한 패키지를 모델 개발을 위한 기술 사양으로 사용할 수도 있습니다.
• 이 기술은 상당한 비용을 들이지 않고도 기존 요구사항 관리 시스템과 통합될 수 있습니다.

끝까지 읽어주신 분들을 위해, 프로토타입이 어떻게 작동하는지 보여주는 비디오 링크.

출처 : habr.com