소프트웨어 상세 설계서(BSW-Application)

혹시 소프트웨어 상세설계서에 BSW와 Application 단간에 flow가 보이도록 명시를 해야 하니?

 

네, 소프트웨어 상세설계서에 BSW(Basic Software)와 Application(응용) 단간의 흐름을 명시해야 합니다. 이는 설계의 핵심적인 부분이며, 특히 자동차 소프트웨어와 같이 안전과 신뢰성이 중요한 시스템에서는 필수적입니다.

상세설계서에 BSW-Application 흐름을 명시해야 하는 이유

상세설계서는 시스템의 내부 동작을 구체적으로 설명하는 문서입니다. BSW와 Application 사이의 흐름을 명시하는 것은 다음의 이유로 매우 중요합니다.

• 시스템 동작의 명확성 확보: Application이 BSW의 어떤 서비스를 호출하고, BSW가 Application에 어떤 데이터를 전달하는지 명확하게 보여줍니다. 이는 개발자들이 코드 구현 시 혼동을 줄이고, 설계 의도를 정확히 파악하도록 돕습니다.
• 인터페이스 정의: BSW와 Application 간의 **인터페이스(Interface)**를 구체적으로 정의합니다. 즉, 어떤 함수를 호출해야 하는지, 필요한 파라미터는 무엇인지, 그리고 반환 값은 무엇을 의미하는지 등을 명시하여 양쪽 모듈 간의 호환성을 보장합니다.
• 기능 안전성 및 신뢰성 확보: BSW는 마이크로컨트롤러(MCU) 드라이버, 통신 스택 등 하드웨어와 밀접한 기본 기능을 담당하며, Application은 실제 사용자의 요구 기능을 구현합니다. 이 둘 사이의 흐름을 명시하면, 고장 발생 시 어떤 로직이 동작해야 하는지, 어떤 안전 메커니즘을 통해 위험을 회피할 수 있는지 등 **기능 안전성(Functional Safety)**을 고려한 설계를 명확히 할 수 있습니다.
• 유지보수 용이성: 시스템에 문제가 발생했을 때, BSW와 Application 간의 흐름이 상세설계서에 명시되어 있으면 문제의 원인이 어느 쪽(BSW, Application 또는 인터페이스)에 있는지 빠르게 파악할 수 있어 유지보수 시간을 단축할 수 있습니다.
• 표준 준수: ISO 26262나 ASPICE와 같은 표준은 소프트웨어의 상세한 설계 문서화를 요구합니다. BSW와 Application 사이의 흐름을 명시하는 것은 이러한 요구사항을 충족하는 중요한 활동입니다.

BSW와 Application 단간의 흐름을 명시하는 방법

명시하는 방법은 다양하며, 주로 다음과 같은 다이어그램이나 문서 구조를 활용합니다.

• 시퀀스 다이어그램(Sequence Diagram): 특정 기능이 동작할 때 BSW와 Application 모듈 간에 어떤 순서로 메시지(함수 호출)가 오가는지 시간의 흐름에 따라 보여주는 다이어그램입니다.
• 활동 다이어그램(Activity Diagram): 특정 프로세스의 흐름을 보여주는 다이어그램으로, BSW와 Application 모듈을 swimlane으로 구분하여 데이터와 제어의 흐름을 나타낼 수 있습니다.
• 인터페이스 상세 문서: 각 모듈의 인터페이스를 테이블 형태로 정리하여, 함수명, 입력 파라미터, 출력 파라미터, 반환 값, 오류 코드 등을 상세하게 기술합니다.

요약하자면, 소프트웨어 상세설계서에 BSW와 Application 간의 흐름을 명시하는 것은 시스템의 견고성과 신뢰성을 확보하고, 효율적인 개발과 유지보수를 가능하게 하는 매우 중요한 작업입니다.

 

 

근데 만약에, 지금 소프트웨어 상세설계서를 만드는 게 공급업체 입장에서, 이 소프트웨어 설계 담당자는 BSW단은 본인이 설계한 것이 아니라 AUTOSAR를 기반으로 BSW를 개발을 하는 타 회사의 플랫폼(BSW)을 사용해서, 그 플랫폼의 내부 구조를 상세하게 잘 모를 경우에는, 소프트웨어 상세설계서에 BSW간과 Application간의 flow를 어느 수준으로 작성해야 할까?

 

타 공급업체의 AUTOSAR BSW 플랫폼을 사용할 경우, 소프트웨어 상세설계서에 BSW와 Application 간의 흐름을 작성할 때 BSW 내부 구조에 대한 상세한 내용은 포함하지 않아도 됩니다. 대신, Application 모듈의 관점에서 BSW를 어떻게 활용하는지에 초점을 맞춰야 합니다.

---

BSW와 Application 간의 흐름 작성 수준

BSW의 내부 구조를 모르는 상황에서는 다음과 같은 수준으로 상세설계서를 작성하는 것이 적절합니다.

1. 인터페이스 중심의 흐름 명시

• 제어 흐름: Application 모듈이 BSW의 어떤 서비스를 호출하여 어떤 동작을 수행하는지 명시해야 합니다. 예를 들어, “Application의 App_ReadSensor 함수는 CanIf_Transmit 함수를 호출하여 CAN 메시지를 전송한다.”와 같이 작성할 수 있습니다.
• 데이터 흐름: Application과 BSW 간에 어떤 데이터가 오가는지 명시해야 합니다. 예를 들어, “BSW의 Com_RxIndication 콜백 함수를 통해 수신된 CAN 데이터가 Application의 App_UpdateData 함수로 전달된다.”와 같이 작성할 수 있습니다.
• 오류 처리: BSW 서비스 호출 시 발생할 수 있는 오류(예: E_NOT_OK)를 Application에서 어떻게 처리하는지 명시해야 합니다.

2. BSW 모듈의 역할 정의

• 상세설계서에는 사용되는 BSW 모듈(예: CanIf, Com, Dio)의 역할과 기능을 Application과의 관계를 중심으로 간략히 설명해야 합니다.
• "이 프로젝트에서 CanIf 모듈은 CAN 메시지 송수신을 담당하며, Com 모듈은 신호 패키징 및 언패키징을 담당한다."와 같이 BSW의 추상화된 기능을 중심으로 기술하면 됩니다.

3. AUTOSAR API 사용 명시

• BSW의 내부 구현을 알 필요 없이, Application이 AUTOSAR 표준 API를 어떻게 사용하는지를 명시하면 충분합니다.
• 예를 들어, "Application은 Dio_WriteChannel 함수를 사용하여 GPIO 핀을 제어한다."와 같이 작성하여 BSW 내부의 하드웨어 드라이버 구조가 아닌, 표준화된 인터페이스를 통해 동작함을 보여줄 수 있습니다.

요약하자면, 상세설계서 작성 시에는 블랙박스(Black Box) 관점에서 BSW 모듈을 바라보면 됩니다. BSW의 내부 구조는 알 필요 없으며, Application이 BSW의 제공 기능을 어떻게 활용하고, 그 과정에서 데이터와 제어가 어떻게 흐르는지를 명확하게 보여주는 데 집중해야 합니다. 이는 설계의 명확성을 확보하면서도 타사 플랫폼의 지적 재산권을 침해하지 않는 합리적인 접근 방식입니다.