1. AUTOSAR의 실무 이해
2. AUTOSAR OS
3. AUTOSAR RTE
4. AUTOSAR MCAL
5. AUTOSAR CAN
6. AUTOSAR FlexRay
 
 
AUTOSAR(AUTomotive Open System ARchitecture)란?  
자동차는 사용자의 편리와 안전을 위해 ECU와 새로운 기능들을 추가하고 있다. 이로 인해 S/W 코드가 증가하고 재사용성이 떨어지는 문제점이 부각됐고, ECU의 효율성과 SW 재사용성을 높이고자 하는 취지에서 AUTOSAR가 등장하게 됐다(하드웨어의 독립성과 소프트웨어 컴포넌트의 표준화를 목표). 
AUTOSAR는 개방형/표준화된 자동차 SW 구조로 자동차 제조사, 부품사, 툴 개발사가 함께 참여해 2002년 BMW 등 Core 멤버들이 초기 논의를 했다. AUTOSAR는 신뢰성 있는 SW 제작을 위한 SW플랫폼 제정, ECU SW 구조 표준화, 향상된 성능과 안전성 그리고 친환경적인 혁신적 전자 시스템 기반 구축에 목표를 두고 2003년 6월 출범(자동차 전자화 표준 단체)했다. AUTOSAR는 OEM과 공급업체 사이에서 SW 모듈의 재사용과 교환가치를 증가시켜 통합된 E/E 아키텍쳐의 복잡한 관리를 향상시키는 것을 목표로 한다(그림 1).



 
그림 2에서 보는 것과 같이 올 상반기에 AUTOSAR 4.1.1 버전이 릴리스됐다. AUTOSAR 4.1.1 버전과 AUTOSAR 4.0.3 버전과의 차이점은 새로운 BSW 모듈이 추가된 것이라 할 수 있다. AUTOSAR 4.0.3 버전은 전체 69개의 모듈로 구성돼 있었는데 AUTOSAR 4.1.1 버전은 Ethernet 모듈인 DoIP(Diagnostic over IP), Sd(Service Discovery), TcpIP(TCP/IP stack)과 J1939 관련 모듈인 J1939Dcm, J1939Nm, J1939Rm 등이 추가돼  77개 모듈로 구성됐다. 
Exploitation Plan에서 보듯이 2016년에는 AUTOSAR가 적용된 ECU가 약 3억 개(2012년 대비 10배)에 달할 것으로 예상된다. 이중 대부분은 AUTOSAR 3.X 와 AUTOSAR 4.X 기반이 될 것으로 예상된다. 현재 대부분 제조사는 2015년부터는 AUTOSAR가 적용된 제품만을 납품받겠다고 하고 있다. 이에 따라 관련 업체들은 AUTOSAR 기반 제품 개발을 위해 많은 노력을 기울이기 있다. 
 
 
일본과 중국 AUTOSAR   
 
일본의 경우 JASPAR(Japan Automotive Software Platform And Architecture)라는 AUTOSAR 대응 단체가 2004년 9월 설립됐다. 현재 116개 정도의 회원사가 활동 중이다. JASPAR는 일본 경제산업성으로부터 연구비를 지원 받아 두 단계에 걸쳐 국가 프로젝트를 수행하고 있다. 1차 국가 프로젝트(2007년~2009년) 시기에는 “AUTOSAR 국산화 및 실제 차량 테스트”를, 2차 국가 프로젝트(10년 ~ 13년)는 “기능안전 ISO 26262 가이드라인 배포 및 AUTOSAR 4.X 구현”을 진행 중이다. 일본은 AUTOSAR를 일본 자동차 표준 개발 플랫폼으로 채택했고, 이에 따라 대부분 제조사의 AUTOSAR 시스템 설계기술 지식 수준이 전문가 수준에 이르고 있다. 일본은 2013년 6월부터 차량용 Ethernet 대응을 위해 AUTOSAR 4.1.1을 중심으로 개발 중에 있다.
중국 CASA(China Automotive Software Architecture)는 2011년 4월 7일 출범했다. 20개 회원사가 활동을 하고 있다. 회원사 중에는 대학도 포함이 돼 있다. 전반적으로 일본처럼 많은 활동을 하고 있지는 않다. CASA에 대한 정보는 CASA 홈페이지인 http://www. chinacasa.org에서 확인이 가능하다. 
 
AUTOSAR 명세서 
AUTOSAR Base 개발을 하는데 있어 가장 필요한 것이 AUTOSAR 명세서라 할 수 있다. AUTOSAR 홈페이지에 접속하면 명세서를 다운로드 받을 수 있다.
 
AUTOSAR 홈페이지: http://www.autosar.org
참고: AUTOSAR 명세서는 공개돼 있기 때문에 회원가입 없이 다운로드 받을 수 있다.
 
명세서를 다운로드 받을 때 자세히 보면 Category가 Standard Specifications(표준 요구사항)과 Auxiliary Material(보조설명)이라고 분류돼 있는 것을 볼 수 있다. 명세서를 다운로드 할 때 Category 별로 정리를 해두면 편리할 것이다.
 
Standard Specification
 - AUTOSAR partnership의 규범적 결과를 설명하는 문서, 모델 또는 포맷이다. 결과물들은 AUTOSAR를 준수하기 위해 명시된 내용을 충족해야만 한다. 
 
Auxiliary Material
- AUTOSAR 파트너십의 표준 스펙의 편리성을 설명하거나 향상시키기 위한 문서, 모델 또는 포맷이다. 보조 자료는 AUTOSAR 표준의 더 나은 이해와 적합한 사용을 위해 읽거나 사용하는 것을 추천하지만, 필수 사항은 아니다.
 
여기서 주의해야 할 사항이 한 가지 있다. 명세서를 다운로드 받을 때 최신 버전 명세서뿐만 아니라 이전 명세서(Release 2.0 ~ Release 4.0)도 받아 두는 것이 좋다. 필자도 경험했듯이 AUTOSAR 최신 명세서에서 이해가 안 되는 부분이 반드시 존재할 것이다. 이런 경우 이전 명세서에서 해당 내용을 확인하면 좀 더 쉽게 이해할 수 있다. AUTOSAR에서는 새로운 버전의 명세서가 작성이 될 때 이전 명세서의 내용 중 일부가 생략된다. 이는 이전 명세서를 알고 있다는 가정 하에 명세서를 작성하기 때문이다. 명세서를 볼 때 이해가 안가는 부분이 있으면 꼭 이전 버전 명세서를 확인하기 바란다.
 
추가적으로 시스템 설계 단계에서는 다음 명세서가 기본이 되니 참조 바란다.
 
Standard Specification
AUTOSAR_MMOD_XMLSchema
AUTOSAR_SWS_RTE.pdf
AUTOSAR_SWS_StandardTypes.pdf
AUTOSAR_TPS_SoftwareComponentTemplate.pdf
 
Auxiliary Material
AUTOSAR_MMOD_MetaModel
AUTOSAR_EXP_VFB.pdf
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
AUTOSAR_SWS_IOHardwareAbstraction.pdf
AUTOSAR_TR_SWCModelingGuide.pdf



 
AUTOSAR Methodology 실무 
AUTOSAR 시스템 개발에 있어 몇 단계에 대한 공통적인 기술 접근법이 요구되는데 이 접근법을 “AUTOSAR Methodology”라고 한다. 그림 5는 AUTOSAR Methodology와 함께 시스템을 만들기 위한 설계 단계들의 개략적인 개요와 그 결과로 생긴 ECU들과 topology를 보여준다. 그림에서 보듯이 1. 시스템 설계 단계, 2. ECU 설정 단계, 3. BSW Generator 단계로 나눌 수 있는데 시스템 설계 단계, ECU 설정 단계는 ARXML을 작성하는 단계로서 전체 과정에 약 70% 이상의 업무량을 차지하고 있다. BSW Generator 단계에서는 앞 1, 2 단계에서 설정 후 생성된 코드를 가지고 Integration 작업을 진행해야 된다.
명세서에서 1, 2, 3 단계에 대한 내용을 살펴보도록 하자. 일단 해당 명세서를 보기 위해서는 UML 툴이 설치돼야 한다. AUTOSAR 필수라고 할 수 있는 EA(Enterprise Architect)를 다운로드 받아 설치하자. EA lite 툴은 Viewer 기능만 제공하며 Editor 기능을 제공하는 툴은 구매해야한다.
이제 EA 툴을 가지고 AUTOSAR _MetaModel.eap와 AUTOSAR_BSW _UML_Model.eap를 확인할 수 있다. 두 파일은 만약 위에 필자가 말한 경로로 다운로드를 했으면 Auxiliary 폴더에 Zip 파일 형식으로 압축이 돼 있을 것이다. 만약 명세서를 다운로드 받지 않았으면 하기 표에 입력돼 있는 URL을 참고하기 바란다. 
 
 
 
AUTOSAR_MetaModel.eap와 AUTOSAR_BSW_UML_Model.eap 파일은 실행시켜보면 알 수 있겠지만, UML로 작성돼 있는 파일이다. 이 두 파일은 AUTOSAR 명세서의 모든 내용이 UML 그림으로 있고, 명세서에 없는 내용도 UML로 구성돼 있다. 만약 AUTOSAR 구현 작업을 할 때 두 파일에 요약된 정보를 가지고도 구현이 가능하니 잘 숙지해 두는 것이 좋다. 만약 UML에 대해 사전 지식이 없다면 AUTOSAR에서는 3가지 Diagram(Class Diagram, Sequence Diagram, State Machine Diagram)이 사용되니 3가지만은 필히 숙지해야 된다.
 
AUTOSAR_MetaModel.eap: 개발 Tool을 만드는데 필수로 XML에 대한 정의를 UML로 표현하고 있다(Class Diagram)
AUTOSAR_BSW_UML_Model.eap: 소스 코드를 구현하는 사람이 필요한 각 BSW모듈에 대한 상관관계와 API 함수의 정의 및 설명이 돼 있다(Sequence Diagram).

 
AUTOSAR_MetaModel.eap 파일은 그림 6과 같이 M1, M2로 구성돼 있다. 시스템 설계 Tool에서 필수로 사용하는 Meta-Model M2는, AUTOSAR에서 작성될 XML 형식에 대한 규약이 스키마 파일인 Autosar_xx.xsd가 UML로 정의돼 있다. UML과 XML은 1 : 1로 동일하다. Autosar_xx.xsd가 UML로 표현된 이유는 스키마 자체로는 차량 설계를 위한 XML 간 제약성을 표현하는데 한계가 있어, 스키마 Autosar_xx. xsd에서 표현하지 못한 것들을 UML로 표현했다. 그리고 이것을 AUTOSAR의 UML Template로 시스템 설계에 있어서 XML 제약성을 규정하고 있다. 그렇지만 UML로 XML 설계의 제약성을 표현하는 것도 제약성이 있어서, 각각의 UML Template을 PDF파일 문서로 추가 설명하고 있다. 재미있는 사실은 스키마 자체에서 XML 간 제약성과 UML Template의 XML 제약성은 각각의 Template PDF 문서에서 설명을 하지 않는다는 것이다. 때문에서 시스템 설계 툴을 만들기는 어렵지 않으나, 시스템 설계가 타당한지를 보는 XML 검증 툴은 만들기 어렵다. 시스템 설계가 타당한지 검증을 하려면 스키마와 UML Template의 이해가 필수다. 
1개의 ECU에 대한 BSW 모듈 설정 툴에서 필수로 사용하는 Meta-Model M1은 AUTOSAR_MOD_ECUConfigurationParameters.arxml 파일이다. 이 파일은 AUTOSAR의 BSW 모듈을 구현하는 각 회사 확장이 필요할 때 독자 기능(AUTOSAR에서 지원하지 않는 기능)을 정의해 XML 규약을 추가해 넣을 수 있다. 대표적으로 AUTOSAR OS, MCAL, FlexRay, RTE를 들 수 있다. AUTOSAR OS 경우는 인터럽트 벡터 테이블 번호, 인터럽트 우선순위 등, MCAL은 MCAL 지원을 위한 Complex Driver 설정기능 등, FlexRay는 독자적인 통신 설정 등, RTE의 경우는 OS 없는 상태에서 작동하는 설정 등이 있다. 
따라서 각 자동차 회사마다 AUTOSAR_ MOD_ECUConfigurationParameters.arxml가 다르고 자동차 회사의 요구에 의해서 가장 많이 수정된다고 볼 수 있다. 
즉, AUTOSAR_MetaModel.eap의 Meta-model을 이해해야 AUTOSAR_MOD_ ECU ConfigurationParameters.arxml을 작성하는 방법을 이해 할 수 있다.
그림 7은 AUTOSAR_BSW_UML_Model.eap 화면으로 Interaction view에서는 각 모듈별 함수의 흐름이 어떻게 되는지를 알아 볼 수 있게 돼 있다. 개발자가 코딩을 할 때 흐름 파악에 도움이 된다. SoftwarePackage의 경우 해당 모듈이 Generator 되면 생성할 코드에 대한 interface 정보와 포함되는 header 파일의 정보를 확인 할 수 있다. 
지금까지 설명한 내용을 정리하면 표1 같이 정리가 된다.  


 
앞에서도 언급했지만 AUTOSAR 개발에 있어 가장 많은 부분을 차지하는 것이 XML 작업이다. 특히 시스템 설계 단계에서는 사용할 RTE API에 대한 설계도 해야되는데, 이때 RTE Generator 기능이 어디까지 지원하는지 우선 확인한 후 작업을 해야한다. 대부분의 Generator가 RTE API를 제공하더라도 모든 기능을 지원하는 것이 아니기 때문에 업체에서 제공하는 문서에서 API 안에 요구사항 항목이 지원되는지 여부를 확인해야 된다. 이 항목들은 대부분 명세서의 주어진 번호로 표기돼 있어 미지원 항목에 대해서는 명세서 확인 후 설계 단계에서 제외를 하는 것이 좋다. 만약 설계 단계에서 미지원 항목을 설계하더라도 RTE Generator에서는 미지원 항목에 대해서는 코드 생성이 안 되게 된다. 
시스템 설계 단계에서 지정된 파일명, 함수명, 변수명이 Generator로 생성되면 적용이 되는데 이때에도 주의해야 될 사항이 있다. 생성된 SWC 소스에서 파일, 함수, 변수에 대해서 변경을 할 경우가 발생하면 시스템 설계 단계에서 변경을 한 후 소스를 다시 생성해야 되기 때문에 초기에 파일, 함수, 변수에 대한 정의를 한 후 설계를 해야한다. 
BSW Generator 단계의 Service SWC는 코드가 자동생성 되긴 하지만 Stub Function으로 생성이 되기 때문에 해당 부분 내용은 개발자가 직접 코드를 작성해줘야 정상 동작할 수 있다. 그림 8의 Sequence Diagram을 보면 EcuM의 경우 BSW 모듈이기는 하나 Service SWC로 Integration Code 영역은 개발자에 의해서 구현이 필요한 부분이다. 즉 Intergration Code 영역으로 호출되는 EcuM_EnableWakeupSource()의 경우는 Stub Function만 생성되는 것이고 해당 Function 내부는 개발자에 의해서 소스 코드가 추가돼야 한다. 
그림 9는 실질적 AUTOSAR에서 개발 업무를 진행할 때 작업해야 될 부분을 도식화 해 놓은 것이다. 



 
시스템 설계 단계 SWC 설계
시스템 설계 단계에 있는 SWC 설계 과정에 대해서 좀 더 알아보도록 하겠다. SWC (Software Component)는 AUTOSAR 컴포넌트 중에서 응용 프로그램의 기본 단위가 되는 컴포넌트를 말한다. SWC는 다른 SWC와 통신하기 위해서 Port를 사용하며 Infrast ructure에 독립적이다. 또한 SWC는 응용 프로그램의 실행 단위가 되며 각 Component는 하나의 <SWC_Name>.c 소스 파일과 대응할 수 있고 System Configuration 단계에서 하나의 ECU에 배치된다. 
SWC는 Atomic Software Component로 구성이 되고 Atomic Software Component는 7가지 Component(Application software component, Sensor-actuator software component, Service software component, ECU-abstraction software component, Complex device driver software component, NVBlock software component, Service Proxy software component) 를 가지고 있다. 
SWC는 서로 통신을 하기 위해 Sender-receiver interface, Client-server interface를 사용한다.


 
Sender-receiver Interface는 Sender가 receiver 측에 다양한 정보를 제공하는 것으로 데이터를 보내는 방식으로 송신자와 수신자로 구분된다. 그림 10은 Sender의 PPort를 통해 DataElement를 송신하면 Receiver Rport로 수신하는 샘플 이미지다. RTE API 중 Sender-Receiver interface를 사용하는 API는 Rte_write, Rte_read, Rte_send, Rte_receive, Rte_Iwrite, Rte_Iread 등이 있다. 
Client-server Interface의 경우 Client는 server가 필요한 때 설정 매개 변수를 전송해 통신을 시작하고 Server는 RTE 형태로 client로부터 들어오는 통신 요청을 대기하다 요청이 오면 해당 정보에 관련된 내용을 전송한다. 즉 Client에게 Server 측의 Operation을 제공하는 것으로 Client가 Server의 Operation 함수를 호출하는 방식이라고 생각하면 된다. 
그림 11은 Client-Server Interface에 대한 Sample로 C/S Interface의 경우 Arguments와 Application Errors의 값에 따라 생성되는 함수의 이름이 변경이 된다. 만약 Arguments와 ApplicationErrors 모두 설정돼 있으면 ApplicationErrors가 설정되기 때문에 Return 값이 Std_Return_Type으로 설정이 되고, Argument가 int data가 설정이 돼 있어 Swc2에 함수는 Std_Return_Type f2(int data)라는 함수가 생성된다.
S/R Interface, C/S Interface에서 보면 각 Port를 연결시켜주는 부분이 있다. 이 부분을 Connector라 하고 AUTOSAR에는 3개의 Connector가 있다.

 
Assembly SW Connector: Swc 간 Port를 연결하는 Connector
Delegation SW Connector: Swc 와 CSwc 간 Port를 연결하는 Connector
PassThrough SW Connector: CSwc 간 Port를 연결하는 Connector
 
특히 PassThrough SW Connector의 경우 AUTOSAR 4.1.1 명세서에 새로 추가된 Connector로 이전 명세서에서는 해당 Connector를 Assembly SW Connector라 했다. 4.1.1에 추가된 사항이니 기억해 두는 것이 좋다. 
첫 회에는 AUTOSAR에 대한 주변국 상황과 실무 작업 시 필요한 기본 지식에 대해 살펴봤다. 다음 회에는 AUTOSAR OS에 대해 살펴볼 것이다. 근래에 들어 AUTOSAR에 대한 관심이 증가되고 웹상에서도 AUTOSAR에 대한 기사가 늘어가고 있는 추세다. AUTOSAR는 내용이 너무 많아 국내에서도 교육과정이 거의 없는 상황이고 전문가도 부족한 실정이다. 매거진에 상세한 설명을 하기에는 무리가 있어 실무를 하는데 알아야 하는 사항 위주로 기재를 하려 노력했다. 
향후 연재에서도 각 주제에 대해 실무에서 필요한 사항을 중심으로 소개할 예정이다.  AE

'경로 및 정보' 카테고리의 다른 글

CVE 2023 21716 Poc  (0) 2023.03.10
arxml-app  (0) 2023.03.09
Argus 기사  (0) 2023.03.09
자동차 버그바운티 경로  (0) 2023.03.07
Verification(검증), Validation(검사)  (0) 2023.03.06
블로그 이미지

wtdsoul

,

Argus 기사

경로 및 정보 2023. 3. 9. 14:41

아르거스, 뛰어난 침투 테스트 기술로 ‘올해 자동차 사이버 보안 혁신상’에 선정 (elec4.co.kr)

 

아르거스, 뛰어난 침투 테스트 기술로 ‘올해 자동차 사이버 보안 혁신상’에 선정

자동차 사이버 보안 분야의 글로벌 선두 기업인 아르거스 사이버 시큐리티(Argus Cyber Security)가 ‘오토테크 혁신상(Auto Tech Breakthrough Awards)’ 시상식에서 ‘올해 자동차 사이버 보안 혁신상(Automoti

www.elec4.co.kr

 

보편적인 테스트 기술 중 하나는 퍼징(Fuzzing)으로, 버그가 나타날 때까지 차량 전자제어 장치(ECU)와 같은 타겟 시스템에 다중의 메시지를 전송하는 방식이다. 가장 이상적인 퍼징 방법은 커버리지 유도 퍼징(Coverage-guided fuzzing)이다. 그러나 커버리지 유도 퍼징은 설정 중 소요되는 시간상의 문제로 임베디드 소프트웨어의 바이너리 코드를 테스트하는 것은 사실상 불가능하다.

 

이 기술은 모니터링, 탐지 및 차량 자산의 취약성 완화를 자동화하는 아르거스 VVM솔루션(차량 취약성 관리 솔루션, Argus Vehicle Vulnerability Management)을 보완한다. 6500만 대 이상의 차량을 보안하기 위한 프로젝트 체결을 통해 자동차 제조업체들이 아르거스에 의존해 차량 취약성 노출 위험을 인지하고, 신속하게 대응할 수 있도록 지원하고 있다

 

 

 

 

 

 

'경로 및 정보' 카테고리의 다른 글

arxml-app  (0) 2023.03.09
AUTOSAR 기술 이해  (0) 2023.03.09
자동차 버그바운티 경로  (0) 2023.03.07
Verification(검증), Validation(검사)  (0) 2023.03.06
품질관리_자동차_품질관리 용어  (0) 2023.03.06
블로그 이미지

wtdsoul

,

https://www.mercedes-benz.com/en/whitehat/

 

Mercedes-Benz: Vulnerability Reporting Policy.

If you have found a vulnerability or other security issues in our infrastructure or products, please feel free to contact us.

www.mercedes-benz.com

Submit report to General Motors (hackerone.com)

 

 

 

 

 

 

 

 

 

01. 벤츠 

02. 보쉬

03. BMW

04. 스텔란티스

05. GM

06. 도요타

07. 테슬라

 

추가 예정

 

 

 

 

 

 

 

 

 

'경로 및 정보' 카테고리의 다른 글

AUTOSAR 기술 이해  (0) 2023.03.09
Argus 기사  (0) 2023.03.09
Verification(검증), Validation(검사)  (0) 2023.03.06
품질관리_자동차_품질관리 용어  (0) 2023.03.06
CAN-BUS With Arduino and Seeed CAN-BUS Shield  (0) 2023.03.06
블로그 이미지

wtdsoul

,

https://velog.io/@yes3427/TIL-DAY4-validation-verification

 

 

TIL DAY4 | validation과 verification 차이

이번주 목요일날 진행만 멘토링에서 멘토님에게 질문을 받았는데 아무말도 하지 못햇다.너무 부끄러웠다. 분명히 공부했다고 생각했는데 나는 개념정리도 제대로 하지 않고함수형 프로그래밍

velog.io

오늘은 멘토링때 대답하지 못한 validation과 verification의 차이에 대해 알아보자!
정보처리기사 공부하면서 암기했던 부분인데 까먹었다..하하ㅏ하..나 hoxy 시험만 보면 모든것을 잊어버리는 병에 걸린건가..
오랜만에 정보처리기사 책을 펼쳐 개념들을 다시 확인해보았다.

validation(검사) : 사용자의 입장에서 개발한 소프트웨어가 고객의 요구사항에 맞게 구현되었는지를 확인하는 것이다.
verification(검증) : 개발자의 입장에서 개발한 소프트웨어가 명세서에 맞게 만들어졌는지 점검하는 것이다.

사실 이러한 개념으로는 정확히 이해가 가지 않기 때문에
조금 더 쉬운 설명들로 이해해보자!

✔ validation

Are we building the right system?

  • 우리가 올바른 제품을 빌드하고 있나?
  • 실제 제품을 검사하고 테스트하는 동적인 방법이다.
  • 최종적으로 만든 결과물이 잘 나왔는지를 말한다.
  • 검증은 항상 코드실행을 수반한다.

✔ verification

Are we building the system right?

  • 우리가 제품을 올바르게 빌드하고 있나?
  • 디자인과 코드를 검사하는 정적인 방법이다.
  • 각 단계의 요구사항을 잘 지켜가며 만들었는지를 확인하는 것이다.
  • 검사는 인간기반의 문서와 파일의 검사이다.

쉽게말하면

validation은 사용자의 관점에서 우리가 제품을 잘 만들고 있는가
verification은 논리적인 관점에서 해당 스펙대로 잘 수현했는가

블로그 이미지

wtdsoul

,

DV : Design Validation / Verification , PV : Puoduct Varification (tistory.com)

 

DV : Design Validation / Verification , PV : Puoduct Varification

품질관리_자동차_품질관리 용어 DV : Design Validation / Verification - 설계 검증 - 설계 출력물이 실제 설계 의도/입력물에의 충족여부를 검증하기 위한 일련의 행위. 시험/평가 설계된 제품이 고객의

novelistgood.tistory.com

품질관리_자동차_품질관리 용어

 

DV : Design Validation / Verification - 설계 검증

- 설계 출력물이 실제 설계 의도/입력물에의 충족여부를 검증하기 위한 일련의 행위. 시험/평가

설계된 제품이 고객의 요구에 만족하고 제품으로서 제대로 기능이 되는지를 검증하는 것으로 사용된 재료가 적정한지(MS), 요구되는 사양을 만족하는지(ES)에 대한 신뢰성 확보를 검증하는 단계

 

PV : Puoduct Varification - 제품 유효성 확인

 - 양산금형/양산공정을 거친 초도품의 설계의도 충족여부를 검증하기 위한 일련의 행위. 시험/평가

4M(양산공정, 양산설비 및 작업자, 양산용 자재)으로 제품을 만들어서 양산된 제품이 문제가 없는지를 검증하는 단계, 통상 P1 단계

 

IRE : Initial Risk Evaluation, 부품품질위험도

 

ESIR :  Engineering Specification Inspection Report, 기술사양 시험 확인 보고서

 

ALL TOOL : 원/부자재 금형, JIG등은 양산시와 동일한 상태

 

FULL TOOL : ALL TOOL조건 + 작업자, 환경, 생산 공정조건 등이 양산용과 동일한 상태

 

MIP : Made In Plant - 공장에서 금형을 이용하여 일정하게 제작하는 부품

 

APQP : Advenced Product Quality Planning - 사전부품 품질계획 및 관리계획

 

PSO : Process Sign-Off - 부품 제조 공정 승인

 

CP : Process Capability - 공정능력(Cpk)

 

VDS : The Vehicle Dependability Study, 구매한 지 3년이 지난 소비자를 대상으로 한 조사 - JD POWER

 

IQS : Initial Quality Study, 신차를 구입한 지 3개월이 지난 소비자를 대상으로 조사 - JD POWER

 

 

VIN : Vehicle identification Number, 차량고유번호, 차량식별번호, 차량로트넘버, 차대번호

 

R&R : Role and Responsibilities - 기업/부서에서 조직원들이 수행해야 하는 역할과 책임을 정하는 것

 

AP : Advanced Pilot, 양산금형 시작단계, P1 이전 단계

 - AP단계 : P1단계에 준하는 부품 투입요건으로 평가

 

P1 단계 : 연구소 파일럿동에서 양산에 준하는 설비 및 금형 지그를 이용하여 처음 행하는 단계로 Main Body Ass'y의 착수 이후 의장조립 완료까지를 포함한다. 품질확보 계획에 따라 품질확인차(법규 인증차 일부 포함)를 조립하면서 품질문제, 작업성, 생산성 등을 확인하며 Body 부품과 의장부품의 Data를 수집하고 작업자 교육을 실시한다. 부품 투입조건은 양산금형(ALL TOOL) 및 치수합격품(Dimension OK)이다.

 

P2 단계 : 연구소 파일럿동에서 P1에 적용한 부품 및 지그 설비의 문제점을 반영한 결과 확인과 미개선, 미완료된 문제점 개선 Data를 수집하는 단계로 작업지도요원의 반복 교육을 통해 작업자 지도 능력을 확보한다. 부품 투입조건은 양산공정(Full Tool), 치수합격품(Dimension OK), 신뢰성(ES, MS) 및 조립성(Function+FIT)합격품이다.

 

M1 단계 : 연구소 파일럿동에서 사용한 설비 및 지그를 양산공장으로 이관하여 양산공장에서 오프라인 및 인라인 생산훈련을 통한 공정원의 작업 숙지 단계이다. 부품 투입조건은 P2 품확치 동일 수준으로 P2 품질수준을 확인한다.

 

M2 단계 : P1, P2 단계의 문제점, 대책, 조치결과를 최종 확인하는 단계로 완성차의 품질, 설비, 치구와 양산성을 최종적으로 확인함을 의미한다.

 

T1 단계 : 양산공장에서 신차 생산을 위한 설비와 지그의 설치 및 개조 등의 설비 트라이아웃 단계로써 설비 단독 시운전을 통한 설비 능력을 확인한다. 공정원에 대하여 오프라인 조립교육을 실시하고 조립공법계획서를 작성 배포한다.

 

T2 단계 : 양산공장에서 P1운영시 발췌된 설비 및 지그 문제점을 개선 반영하고 흐름 시운전을 통한 P1 품질 수준을 확인하며, 양산성을 확인하는 단계이다. 오프라인 및 인라인 작업교육을 통한 작업편성 조정 등 작업성을 확인한다. 부품 투입조건은 P1 품확차 동일 수준이다.

 

 

 

블로그 이미지

wtdsoul

,

 

Introduction: Hack Your Vehicle CAN-BUS With Arduino and Seeed CAN-BUS Shield

Modern Vehicles all come equipped with a CAN-BUS Controller Area Network, Instead of having a million wires running back and forth from various devices in your car to the battery, its making use of a more clever system.

All electronic functions are connected to the TIPM, (Totally integrated Power Module), such as solenoids/relays to lock the doors or mini motors to wind the windows ect ect.

From each node (IE Switch pod that controls your windows or electric door locks) it broadcasts a message across the CAN. When the TIPM detects a valid message it will react accordingly like, lock the doors , switch on lights and so on.

WHY?
Because you can :-)

What you need.
Arduino UNO + Seeed CAN-BUS Shields
You can get the CAN-BUS Shield from SeeedStudio.com

Add TipAsk QuestionCommentDownload

Step 1: Setting Up an Interface for Connecting Your Laptop.

The Seeed CAN-BUS Shield has a header dedicated for the CAN-High (+) and CAN-Low (-)

Obviously all vehicles aren’t the same so the location to tap into the CAN-BUS will differ from vehicle to vehicle.
In this instructable I’m using a Jeep Wrangler (AKA Jeep JK) 2010, Rubicon 2DR , with a manual shifter.

The easiest way into the bus is to connect into the radio, at the back of the radio it has a White/Orange (- CAN-L) and White Grey ( + CAN-H ) wire. From there I routed the cable through to the glove box of the Jeep.

Add TipAsk QuestionCommentDownload

Step 2: Programming the Arduino to Accept Messages From the CAN-BUS

First of all you need the Seeed CAN-BUS Shield’s Library downloadable at GIT-HUB

After downloading the CAN-BUS Library you need to import it into your Arduino Libraries folder.
In the Arduino Editor Select Sketch --> Import Library --> Add Library and then point it to the Zip file you downloaded, (No need to unzip the contents it can be imported as is.

Tip: You might have to rename the zip as the Arduino IDE does not like unusual characters , so maybe try canbus.zip instead of can-bus.zip

Something important to note:

The CAN-BUS Shield library comes with a working example, it does not include getting the CAN-ID which is quite important to know when analysing the data, So i modified it slightly to include the ID also to seperate all values with a comma so that you can use it as a csv file.

Copy and paste the below code into your Arduino Sketch Editor.

#include "mcp_can.h"<br>
INT32U canId = 0x000;
unsigned char len = 0;
unsigned char buf[8];
char str[20];

void setup()
{    
Serial.negin(115200);
START_INIT:
if(CAN_OK == CAN.begin(CAN_125KBPS))
    {
        Serial.println("CAN BUS Shield init ok!");
    }
    else
    {
        Serial.println("CAN BUS Shield init fail");
        Serial.println("Init CAN BUS Shield again");
        delay(100);
        goto START_INIT;
    }
}
void loop()<br>{
    if(CAN_MSGAVAIL == CAN.checkReceive())
    {
        CAN.readMsgBuf(&len, buf);
        canId = CAN.getCanId();
        
        Serial.print(canId);Serial.print(",");
        for(int i = 0; i<len; i++)
	{
		Serial.print(buff[i]);Serial.print(",");
	}
	Serial.println();
   }
}

Hit the upload button to upload the sketch.

Add TipAsk QuestionCommentDownload

Step 3: Connecting to the Arduino + CAN-BUS Shield to Get CAN Data

Now you need to make sure the CAN-BUS Shield has been connected to the vehicle's CAN-BUS, via the CAN-H & CAN-L Connector.

If you are sure everything has been connected then use putty to connect to the shield via Serial.

Putty is actually a SSH Client but can also handle serial data and it works great for this purpose.

Look at the Image attached to this step for the Serial port configuration.

Once you connect, Your vehicle's CAN-BUS will bombard putty with CAN-BUS Data.

Add TipAsk QuestionCommentDownload

Step 4: Analyze the Data

From here you need to figure out how to detect the messages, such as turning on lightts, open windows ect ect.

When connecting with putty you can log all incomming data to file as explained in the screenshot from the previous step.

Connect and log to a file called file1.csv and let it run with all windows closed, vehicle's key in on position but not started, and let it run for about 5 minutes, Kill the putty session, then restart the Arduino (The Sketch does not clear the buffer), And this time log all data to file2.csv , once putty starts duming data, quickly press a buton (Only one at a time cus you will not know which message goes to which button), once you pressed a button a few times quickly disconnectputty from the can bus.

So theoretically all messages in File2.csv thats also in File1.csv should be ignored/filtered the messages thats left over in File2.scv should be the message button presses.

If you have some programming skills you might find a better way to manage this.
I cretated a basic application in VB6 , you can look for more information about the tool on my Blog
Unfortunatly the application is a bit incomplete, eventhough it has the capability to connect directly to the Arduino Via Serial it doesnt work propperly, so please ignore the Serial Connection part.

It will basically take the fisrt file run which you were dumping data for ~5 Minutes (ignoredatabase.can) and incomming.can as the log file which includes button presses.

I encourage you to find a better way to analyse the data as this can be very stime consuming.

Add TipAsk QuestionCommentDownload

Step 5: Sending a Message Into the CAN-BUS

To send a message into the CAN-BUS is pretty straight forward.

The below will send the "Sway-Bar" disconnect on a Jeep Wrangler.

Note the CAN-ID needs to be converted into HEX format, an easy way to convert it is to use the Windows Calculator, Using "Programmer Mode" for Windows 7 Calculator

From the below code you can see its sending it to CAN-ID 2B0 = 688

#include <mcp_can.h><br>#include <spi.h></spi.h></mcp_can.h>
void setup()
{
    Serial.begin(115200);
  
START_INIT:
    if(CAN_OK == CAN.begin(CAN_125KBPS))                   // init can bus : baudrate = 500k
    {
        Serial.println("CAN BUS Shield init ok!");
    }
    else
    {
        Serial.println("CAN BUS Shield init fail");
        Serial.println("Init CAN BUS Shield again");
        delay(100);
        goto START_INIT;
    }
}
void loop()
{
    unsigned char stmp3[4] = {3, 0, 3, 0};
    CAN.sendMsgBuf(0x2B0, 0, 4, stmp3);  
    delay(10000); 
     
}
Add TipAsk QuestionCommentDownload

Step 6: A Prototype Built Using the Information From This Instructable

 

Not going into much detail, this is just to show you whats possible.

This Arduino + Seeed CAN-BUS Shield has an added feature, I built a Button & 4 LED Display.
When pressing the red button it will cycle through all posible LED states and each state represents a feature.

Pressing the yellow button will send the message to the bus.

블로그 이미지

wtdsoul

,

https://dovecot.org/list/dovecot/2009-July/040921.html

 

[Dovecot] AUTH PLAIN error with Thunderbird and Dovecot 1.2

 

dovecot.org

https://book.hacktricks.xyz/network-services-pentesting/pentesting-pop

[Dovecot] AUTH PLAIN error with Thunderbird and Dovecot 1.2

Bernhard Schmidt berni at birkenwald.de
Sun Jul 5 22:54:02 EEST 2009


Hi,

a few days ago I started to get some complaints about authentication
delays from Thunderbird POP3 users. After some debugging it turned out
that the problem was introduced somewhere between 1.2rc3 and 1.2rc7
(1.2.0 is still affected).

A session with Thunderbird 2.0.0.22 against 1.2rc3 looks like this:

<<< +OK Dovecot ready.
>>> CAPA
<<< +OK
<<< CAPA
<<< TOP
<<< UIDL
<<< RESP-CODES
<<< PIPELINING
<<< STLS
<<< USER
<<< SASL PLAIN LOGIN
<<< .
>>> AUTH PLAIN
<<< + 
>>> <base64>
<<< +OK Logged in.

and with 1.2.0 (same client, same config, just replaced the server
binaries)

<<< +OK Dovecot ready.
>>> CAPA
<<< +OK
<<< CAPA
<<< TOP
<<< UIDL
<<< RESP-CODES
<<< PIPELINING
<<< STLS
<<< USER
<<< SASL PLAIN LOGIN
<<< .
>>> AUTH PLAIN
[ 2 seconds delay ]
<<< -ERR Authentication failed.
>>> AUTH LOGIN
[ 5 seconds delay ]
<<< + <base64>
>>> <base64>
<<< + <base64>
>>> <base64>
<<< +OK Logged in.

In the log I see

mail dovecot: auth(default): plain(?,77.2.39.xx): invalid input

Does anyone have an idea? 

# dovecot -n
# 1.2.0: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.28.2 x86_64 Debian squeeze/sid ext4
protocols: imap imaps pop3 pop3s managesieve
listen: *, [::]
ssl_cert_file: /etc/ssl/private/pop3.mucip.net.crt
ssl_key_file: /etc/ssl/private/pop3.mucip.net.key
disable_plaintext_auth: no
login_dir: /var/run/dovecot/login
login_executable(default): /usr/lib/dovecot/dovecot/imap-login
login_executable(imap): /usr/lib/dovecot/dovecot/imap-login
login_executable(pop3): /usr/lib/dovecot/dovecot/pop3-login
login_executable(managesieve):
/usr/lib/dovecot/dovecot/managesieve-login
login_process_per_connection: no
verbose_proctitle: yes
mail_uid: 5000
mail_gid: 5000
mail_location:
maildir:/var/mail/vmail/%1u/%u:INDEX=/var/cache/dovecot/%1u/%u
maildir_stat_dirs: yes
mail_executable(default): /usr/lib/dovecot/dovecot/imap
mail_executable(imap): /usr/lib/dovecot/dovecot/imap
mail_executable(pop3): /usr/lib/dovecot/dovecot/pop3
mail_executable(managesieve): /usr/lib/dovecot/dovecot/managesieve
mail_plugins(default): quota imap_quota fts fts_squat
mail_plugins(imap): quota imap_quota fts fts_squat
mail_plugins(pop3): 
mail_plugins(managesieve): 
mail_plugin_dir(default): /usr/lib/dovecot/imap
mail_plugin_dir(imap): /usr/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/lib/dovecot/pop3
mail_plugin_dir(managesieve): /usr/lib/dovecot/managesieve
imap_idle_notify_interval(default): 900
imap_idle_notify_interval(imap): 900
imap_idle_notify_interval(pop3): 120
imap_idle_notify_interval(managesieve): 120
auth default:
  mechanisms: plain login
  verbose: yes
  passdb:
    driver: ldap
    args: /etc/dovecot/dovecot-ldap.conf
  userdb:
    driver: ldap
    args: /etc/dovecot/dovecot-ldap.conf
  socket:
    type: listen
    client:
      path: /var/spool/postfix-mailout/private/auth
      mode: 432
      user: postfix
      group: postfix
    master:
      path: /var/run/dovecot/auth-master
      mode: 384
      user: vmail
plugin:
  quota: maildir
  quota_rule: *:storage=500M


Thanks,
Bernhard



More information about the dovecot mailing list

 

블로그 이미지

wtdsoul

,

https://github.com/ForgeRock/openam-community-edition/blob/master/openam-federation/OpenFM/src/main/deployable-war/fam-noconsole.list

 

GitHub - ForgeRock/openam-community-edition: Access Management - AuthN, AuthZ, SSO, Fedaration

Access Management - AuthN, AuthZ, SSO, Fedaration. Contribute to ForgeRock/openam-community-edition development by creating an account on GitHub.

github.com

SAML2 이하 경로

블로그 이미지

wtdsoul

,

https://www.secureworld.io/industry-news/critical-vulnerabilities-vehicle-gps

 

Critical Vulnerabilities Discovered in Popular Vehicle GPS Tracker

Six security vulnerabilities have been found in a popular GPS tracker used on vehicles around the world. How to prevent your car from being hacked.

www.secureworld.io

https://nvd.nist.gov/vuln/detail/CVE-2022-37418

 

NVD - CVE-2022-37418

CVE-2022-37418 Detail Description The Remote Keyless Entry (RKE) receiving unit on certain Nissan, Kia, and Hyundai vehicles through 2017 allows remote attackers to perform unlock operations and force a resynchronization after capturing two consecutive val

nvd.nist.gov

 

'경로 및 정보' 카테고리의 다른 글

AUTH PLAIN error with Thunderbird and Dovecot 1.2  (0) 2023.03.05
SAML2 이하 경로  (0) 2023.03.05
validation / verification 차이  (0) 2023.03.03
iso 21434 참고  (0) 2023.03.03
Embedded Security Testing  (0) 2023.03.03
블로그 이미지

wtdsoul

,

https://www.a-ha.io/questions/49a15af8f21b921bada87a36ee1dfd80

 

 

두가지 용어는 저도 항상 헷갈려서 정리한 적이 있는데 내용 공유드립니다.

Verification (확인)

- 제품을 올바르게 만들고 있는가?

- 명세된 대로 기술되었고 동작하는지 보는 것

- 개발중간산출물에 기술된 내용 자체가 맞는지를 보는 것

- 이전단계에서 만들어진 산출물을 근거로 한 단계의 산출물을 검사하는 것

Validation (검증)

- 올바른 제품을 만들고 있는가?

- 원래 사용자가 원한 대로 개발되었는지를 확인하는 것

- 명세대로 되어 있어도 사용자가 실제로 원한 것이 아닌 사항을 사용자 관점에서 결함으로 보는 활동

만약 개발자가 엉뚱한 명세를 가지고 개발하고 테스트하였다면 Verification 측면에서는 우수한 품질이라고 할 수 있으나 Validation 측면에서는 우수하지 않은 품질이라고 할 수 있다.

 

 

블로그 이미지

wtdsoul

,