예제와 설계 목표
이 장에서 할 일
이 장은 화면 조작 없이 읽는 장이다. 이 튜토리얼이 만드는 예제 차량과 설계 목표를 정리하고, 차량 수준 요구에서 PNC(Partial Network Cluster) 3개를 어떻게 도출했는지를 따라간다.
PNC 설계는 편집기 하나에서 끝나지 않는다. 이 장의 마지막에서는 PNC가 AUTOSAR 메타모델의 어느 요소에 걸쳐 있고, 그 요소를 PAIO의 어느 편집기가 소유하는지를 표로 확인한다. 이 표가 이후 장들의 지도 역할을 한다.
시작하기 전에
- PAIO를 설치해 두면 좋지만, 이 장에는 편집기 조작이 없다. 읽기만 해도 된다.
- 모델 작업은 다음 장인 토폴로지 설계에서 프로젝트가 열려 있지 않은 PAIO 창으로 시작한다. 이 장에서 만들어 둘 것은 없다.
- 이 튜토리얼 전체의 준비물과 장별 흐름은 PNC 설계 튜토리얼에 정리되어 있다.
설계 목표
이 튜토리얼의 목표는 다음 차량 수준 요구를 AUTOSAR PNC로 모델링하는 것이다.
문이 열리면 Comfort 망만 깨우고, 후진 기어에서만 주차 보조 망이 살아나며, 트레일러가 붙었을 때만 트레일러 망이 동작한다.
완성된 모델은 다음 조건을 모두 만족한다.
- PAIO의 VALIDATION 패널에서 보고 항목이 0건이다(System 에디터와 검증).
- 익스포트한 ARXML은
PNC_COM.arxml의 익스포트 자체에서 생기는 오류를 빼면 AUTOSAR R25-11 스키마 검사에서 0 오류이다(ARXML 익스포트).
예제 차량은 조널 아키텍처이다. HPC 하나가 AUTOSAR Adaptive Platform으로 동작하고, 그 아래 Zone ECU 3개가 Classic Platform으로 동작하며, 각 Zone 아래 CAN FD 버스에 말단 ECU 10개가 매달린다. HPC와 Zone ECU는 백본 Ethernet으로 이어진다.
PNC란 무엇인가
PNC(Partial Network Cluster)는 함께 깨어나고 함께 잠드는 기능 집합이다. 차량이 켜져 있어도 필요 없는 ECU와 통신은 잠들어 있게 해, 전력을 아끼고 버스 부하를 줄이는 것이 목적이다.
PNC 하나는 다음 네 가지로 정해진다.
| 구성 요소 | 뜻 |
|---|---|
| 식별자(PNC identifier) | NM PDU 안의 PNC 비트 벡터에서 이 PNC가 차지하는 비트 번호 |
| 참여 물리 채널 | 이 PNC가 켜지면 함께 깨어나는 CAN 채널과 Ethernet VLAN |
| 통신 단위 | 이 PNC가 켜고 끄는 I-PDU Group(Rx/Tx 쌍) |
| 기능 단위 | 이 PNC가 제어하는 SWC 포트의 묶음. AUTOSAR에서는 PortGroup, 이 튜토리얼에서는 VFC(Virtual Function Cluster)라고 부른다. |
설계할 때의 요령은 하나이다. 기능을 차량 상황(웨이크업 트리거) 별로 묶고, 그 기능에 참여하는 ECU와 버스를 따라가면 PNC와 그 물리 채널이 저절로 결정된다.
차량 시나리오에서 PNC 3개 도출하기
앞의 요구 문장에는 서로 다른 차량 상황이 셋 있다. 상황마다 참여 ECU와 버스를 적으면 다음 표가 된다. 이 표가 이 튜토리얼 전체의 설계 명세이다.
| PNC | 식별자 | 차량 상황(웨이크업 트리거) | 참여 ECU | 관련 버스 | 기능 |
|---|---|---|---|---|---|
PNC_Comfort | 17 | 도어 언락, 도어 개방(DoorStatus 프레임) | DoorCtrl_FL, DoorCtrl_FR, SeatCtrl_FL, SeatCtrl_FR, MirrorAct_FL, MirrorAct_FR, WindowSw_FL, WestZone, EastZone, HPC의 ComfortApp | WestCAN, EastCAN, VLAN_Body | 도어, 시트, 미러, 윈도우 편의 기능. 좌우 두 Zone에 걸친다. |
PNC_ParkAssist | 18 | 후진 기어. HPC의 ParkAssistFG 상태가 Active가 될 때 | ParkSensor_RR, SouthZone, HPC의 ParkAssistApp | RearCAN, VLAN_Rear | 후방 거리 센서 값을 SouthZone이 SOME/IP로 HPC에 제공한다. AP 쪽에서 FunctionGroup 상태로 요청하는 PNC이다. |
PNC_Trailer | 19 | 트레일러 체결(TrailerStatus 프레임) | TrailerModule, TailLamp_RR, SouthZone, HPC의 VehicleStateApp | RearCAN, VLAN_Rear | 트레일러 램프 제어. 체결되지 않은 평소에는 완전히 잠든다. |
PNC_Comfort만 트리거가 CAN 프레임이고, PNC_ParkAssist는 HPC 쪽 FunctionGroup 상태에서 출발한다는 점이 뒤에서 갈린다. 프레임 트리거는 커넥터의 웨이크업 속성으로(PNC 정의와 커넥터 PNC 속성), FunctionGroup 트리거는 AP 머신의 NM 네트워크 핸들로(AP 머신 — NM 핸들과 FunctionGroup) 표현한다.
완성된 모델에서 PNC와 물리 채널의 관계는 PNC 다이얼로그의 MATRIX 탭에서 한눈에 볼 수 있다.
그림 1-1. 완성 예제의 MATRIX 탭. 행은 PNC 3개, 열은 물리 채널이다. PNC_Comfort 행은 EastCAN, WestCAN, VLAN_Body에, PNC_ParkAssist와 PNC_Trailer 행은 RearCAN, VLAN_Rear에 표시가 있다. 위 표의 "관련 버스" 열과 같은 값이다. 이 화면은 PDU GROUPS·MATRIX·NM VECTOR 검토에서 다시 본다.
PNC 식별자를 17, 18, 19로 잡은 이유
PNC 식별자는 이름표가 아니라 NM PDU 안의 비트 번호이다. 따라서 아무 숫자나 쓸 수 없고, NM PDU에서 PNC 비트 벡터가 놓인 자리 안에 들어가야 한다.
이 예제는 CanNm 표준 배치를 따른다.
| NM PDU 위치 | 내용 |
|---|---|
| Byte 0 | CBV(Control Bit Vector) |
| Byte 1 | NID(Node Identifier) |
| Byte 2 ~ Byte 7 | PNC 비트 벡터 |
그래서 전역 설정이 PNC VECTOR OFFSET 2, PNC VECTOR LENGTH 6이 되고, 쓸 수 있는 식별자는 비트 16부터 63까지이다. 계산은 다음과 같다.
시작 비트 = offset × 8 = 2 × 8 = 16
끝 비트 = (offset + length) × 8 − 1 = (2 + 6) × 8 − 1 = 63
AUTOSAR는 이 범위를 constr_3040으로 규정한다. 범위를 벗어난 식별자는 PAIO 검증에서 오류로 보고된다.
참고. 이 예제의 초안에서는 식별자를
8,9,10으로 잡았다. 비트16보다 작아constr_3040위반이었고, PAIO의 검증 패널이 이를 지적했다. 그래서17,18,19로 옮겼다. PNC 정의와 커넥터 PNC 속성에서는 이 과정을 그대로 따라 하며 오류를 내고 고쳐 본다.
PNC VECTOR OFFSET과 PNC VECTOR LENGTH의 실제 값은 PDU GROUPS·MATRIX·NM VECTOR 검토의 NM VECTOR 탭에서 확인한다.
PNC가 걸친 5개 층
PNC 설계가 편집기 하나에서 끝나지 않는 이유는, AUTOSAR 메타모델에서 PNC가 여러 요소에 나뉘어 기록되기 때문이다. PAIO는 층마다 담당 편집기와 저장 파일이 다르다.
| AUTOSAR 요소 | 역할 | PAIO 편집기 / 파일 | 해당 장 |
|---|---|---|---|
PncMapping(SystemMapping) | PNC 식별자, 참여 물리 채널, I-PDU Group, VFC, 서비스 인스턴스, 웨이크업 프레임 | System 편집기의 PNC 다이얼로그 / SYSTEM.io.model | 3장, 7장, 8장 |
CommunicationConnector의 PNC 속성 | pncGatewayType, 웨이크업 CAN ID와 마스크, PNC 필터 배열 마스크 | System 편집기 속성 패널 / IVC.io.model | 3장 |
ISignalIPduGroup | PNC가 켜고 끄는 통신 단위(Rx/Tx, 컨테이너와 리프) | Signal 편집기와 PNC 다이얼로그 / SIGNAL.io.model | 4장 |
PortGroup(= VFC) | PNC가 제어하는 기능 단위. SWC 포트의 묶음 | 원자 SWC의 PortGroup은 VFB 편집기, 컴포지션과 응용 AA의 멤버 포트는 PNC 다이얼로그의 SWC HIERARCHY / SWC/*.swc.io.model | 6장, 7장 |
NmNetworkHandle과 NmHandleToFunctionGroupStateMapping | AP 머신(HPC)이 PNC를 요청하고 해제하는 창구, FunctionGroup 상태 연동 | VFB 편집기의 Machine Configuration 다이얼로그 MODULE 탭의 Network Management / Module/Machine/HPC.machine.io.model | 9장, 10장 |
CanNmCluster, UdpNmCluster | NM PDU 안의 PNC 비트 벡터(오프셋과 길이), NM 노드 | System 편집기의 NM 설정과 PNC 다이얼로그의 NM VECTOR 탭 | 3장, 8장 |
ServiceInstance(SOME/IP 제공자와 소비자)는 이 표에 따로 두지 않았다. PNC 매핑이 참조하는 값이며, Interface 편집기와 System 편집기에서 5장에 만든다.
참고. 표의 마지막 두 행은 같은 "NM" 이라는 이름을 쓰지만 서로 다른 것이다.
NmNetworkHandle은 AP 쪽에서 PNC를 요청하는 소프트웨어 창구이고,CanNmCluster와UdpNmCluster는 버스 위에서 NM PDU가 실제로 어떻게 생겼는지를 정한다.
확인하기
- PNC 3개의 이름, 식별자, 트리거, 관련 버스를 표에서 설명할 수 있다.
- 식별자
17,18,19가 왜 유효하고8,9,10은 왜 아닌지 계산으로 설명할 수 있다. - PNC 설계가 System 편집기(PNC 다이얼로그 포함), Signal, Interface, VFB, Machine Configuration에 나뉘어 기록된다는 점을 이해했다.
다음 단계
토폴로지 설계에서는 프로젝트가 열려 있지 않은 PAIO 창으로 시작해 프로젝트 PNC를 만들고, 이 장에서 정리한 차량의 뼈대를 System 편집기에 그린다.