Automotive Software

#include #include #include /* user defined macro */ #define COUNT_INIT_VALUE 0x00 #define COUNT_DUMMY_VALUE 0xA0 pthread_once_t InitOnce = PTHREAD_ONCE_INIT; /* it needs to be initialized as PTHREAD_ONCE_INIT */ int ClientCount = COUNT_DUMMY_VALUE; void init_ClientCount( void ) { printf("ClientCount(), Before : ClientCount = %d\n", ((COUNT_DUMMY_VALUE == ClientCount)? COUNT_DUMMY_VALUE : ClientC..

오토사 스펙이 진화?(2.x, 3.x 그리고 4.x)하면서 오토사 프로젝트의 개발 절차 역시 그 성숙도가 높아져 가고 있다. 초기(적어도 7, 8년, 3.x 시절) 오토사 프로젝트만 해도 사실 사양서에 기술된 내용을 충분히 적용하여 제어기 기능 요구서를 작성하는 차량 제조사가 거의 없었던 것으로 기억된다. 독일의 제조사들은 기존에 제공하던 네트워크 데이터베이스 파일에 몇 가지 오토사 특성화된 속성을 정의한 후 ARXML 변환을 통해 네트워크 관련 기능 정의서를 대부분 제공할 수 있었고, 몇몇 제조사들은 자사 플랫폼에 특성화된 SWC 부분만을 오토사 사양에 맞추어 작성하여 부품사에 배포하는 것이 대부분이었다. 일본이나 그 외 유럽 제조사들은 경우에 따라 액셀파일 등에 제어기 개발에 필요한 네트워크 신호정보..

접속 클라이언트 수가 다중 쓰레드에 의해 공유되고, 서버의 첫 구동 시 한 번만 초기화되어 현재까지 접속한 클라이언트의 수를 나타내고 싶을 때, 당연히 생성 쓰레드마다 클라이언트 수를 증가시키겠지만, 증가 전 이 접속 클라이언트 수의 초기화 여부를 어떻게 확인할 것인가? 다중 쓰레드 환경에서 간단한? 방법은... 하나의 초기화 상태 변수를 선언하고 이 변수를 보호할 뮤텍스를 하나 정적으로 선언한 후 그 뮤텍스 보호하에 그 상태 변수의 값을 확인한 후 초기화 여부를 결정 하는 방법일 것이다. 하지만, 뮤텍스를 사용하기 위해 이 뮤텍스 넘을 초기화하기 위한 pthread_mutex_init()을 호출해야 하는데, 이 함수 역시 한 번만 호출되어야 하므로, 다시금 상기 절차를 재귀적(recursively)으로..

나의 포직스(POSIX) 이야기 사실 제목을 "나의 리눅스 또는 유닉스 이야기"로 해야 될지 망설여진다. 나에게 포직스라는 개념조차 없던 시절, 임베디드 리눅스를 통해 처음 포직스라는 단어를 알게 되었지만, 이내 머릿속에서 잊히고 이러한 계열의 운영체제는 단지 유닉스(UNIX)라는 이름으로 인식한 채 대부분의 시간을 지내왔기 때문이다. 물론 리눅스가 포직스 운영체제는 아니지만 그래도 포직스에서 정의하는 기능을 제공하는 포직스 같은 (POSIX Like) 운영체제이고 실제 QNX와 같은 다른 상용 포직스 호환 운영체제와 실제 개발 면에서 크게 다른 점이 없다. (물론, 세부적인 지원 기능 또는 타입 구조체 정의 등은 차이가 있지만) 처음 임베디드 리눅스를 접할 때만 해도 난 임베디드 리눅스 개발자로 먹고살..

클래식 오토사 / 오토사 아키텍처 우선 아키텍처에 대해 간단히 알아보면, 오토사는 아래와 같이 크게 3개의 계층으로 구성된다. 사실 소프트웨어 컴포넌트 간의 인터페이스를 추상화해 주는 RTE를 제외하면 이미 많은 개발자들이 사용하는 기본적인 소프트웨어 구조와 크게 다를 것이 없다. 우리가 일반 PC상에서 구현하는 것과 같은 응용프로그램을 애플리케이션 계층(Application Layer)에 구현할 수 있고, 이 응용프로그램이 구동될 수 있도록 지원해주는 운영체제, 메모리/통신/하드웨어 관련 소프트웨어들이 베이직 소프트웨어(BSW) 계층에 구현되어진다. 굳이 PC 환경에서의 프로그램과 비교한다면, RTE를 포함한 BSW 계층을 흔히 Linux, Windows와 같은 운영체제 영역으로 치부할 수 있을 것이다..

2011년 국내에서 처음 오토사를 접할 때만 해도 몇몇 업체만이 관심을 가지고 예비(타당성) 조사 형식(Feasibility study)의 프로젝트를 진행하고 있었지만, 이제는 한국에서도 많은 업체들이 오토사에 관심을 가지고 또 실제로 오토사(또는 전기/전자 설계)를 기반으로 하는 시스템 및 제어기(소프트웨어) 설계를 진행하고 있는 것으로 보인다. 물론 그 당시와 비교해서 국내에 오토사 솔류션을 제공하는 국내/외 업체들도 많이 늘었지만, 결국은 차량 제조사(OEM)들의 의지가 반영된 결과라 생각된다. 차량 전장 개발 절차의 구조상 제조사가 요구사항을 정의하고 부품사에게 전달하기 때문이다. 물론, 이전에는 역방향으로 진행되는 경우(부품사가 사양을 정의해서 제조사에 제안하는)도 허다했지만, 이제는 개발절차가..