WO2021107183A1 - Autosar 기반의 소프트웨어 설계 방법 및 이를 수행하기 위한 장치 - Google Patents

Autosar 기반의 소프트웨어 설계 방법 및 이를 수행하기 위한 장치 Download PDF

Info

Publication number
WO2021107183A1
WO2021107183A1 PCT/KR2019/016473 KR2019016473W WO2021107183A1 WO 2021107183 A1 WO2021107183 A1 WO 2021107183A1 KR 2019016473 W KR2019016473 W KR 2019016473W WO 2021107183 A1 WO2021107183 A1 WO 2021107183A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
component
port
autosar
cause
Prior art date
Application number
PCT/KR2019/016473
Other languages
English (en)
French (fr)
Inventor
서용진
Original Assignee
주식회사 알티스트
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 알티스트 filed Critical 주식회사 알티스트
Publication of WO2021107183A1 publication Critical patent/WO2021107183A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G06F8/24—Object-oriented
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/75—Structural analysis for program understanding

Definitions

  • the present invention relates to an open automobile standard software architecture technology, and is a research result of "development of high-reliability and adaptive electric field SW platform technology for intelligent vehicle service” carried out with support from the Ministry of Science and ICT.
  • AUTOSAR AUTomotive Open System Architecture
  • ISO 26262 The automotive functional safety international standard is a standard applied to safety-related electronic/electrical devices in a vehicle, and software installed in electronic/electrical devices is also included in the applicable subject. The most important thing among the actions for functional safety suggested by the automotive functional safety international standard is to derive safety requirements.
  • An object of the present invention is to provide an AUTOSAR-based software design method capable of reflecting and identifying safety requirements and an apparatus for performing the same.
  • AUTOSAR-based software design method is a method performed in a computing device having one or more processors and a memory for storing one or more programs executed by the one or more processors, AUTOSAR (AUTomotive Open System Architecture) A software design stage that defines the structure of the software based on the manual; a defect analysis step of analyzing possible defects from the designed software; and a safety monitoring design step for detecting defects occurring during operation of the software.
  • AUTOSAR AUTomotive Open System Architecture
  • the software design step may include defining interfaces necessary for realizing the functions of the software according to a user input based on the AUTOSAR manual; and defining components necessary for realizing a function of the software, and defining each of the interfaces may include specifying defects that may occur in a communication process between the components.
  • the step of defining the components includes defining a provision port and a request port for communication with other components for each component, and the step of defining each of the interfaces includes: at the provision port and the request port It may include the step of specifying a defect that may have occurred.
  • the step of analyzing the defect may include deriving a cause and effect relationship between a cause of a possible defect from the software and an effect thereof.
  • a defect of the request port of the component is set as a cause
  • a defect of the provision port of the component is set as an effect, and between the request port and the provision port of each component included in the software.
  • Cause and effect relationships can be derived.
  • the step of analyzing the defect may include: assigning a level to one or more of a probability of occurrence of a defect and a degree of severity of the derived cause and effect relationship between the request port and the provision port of each component; and defining an action method when a fault occurs with respect to a cause and effect relationship between the request port and the provision port of each component derived according to the given level.
  • a level may be assigned to the cause and influence relationship based on a preset importance level of each component and the number of times an interaction occurs in each component.
  • the step of analyzing the defect may further include deleting those whose level is less than a preset reference level among the derived cause and effect relationships between the request port and the provision port of each component.
  • the safety monitoring design step may include generating a monitoring component for monitoring a fault occurring during the operation of the software based on the cause and effect relationship between the request port and the provision port of each component and the action method. .
  • the monitoring component may be provided to derive a data control flow in the software from a cause and effect relationship between the request port and the provision port of each component.
  • the safety monitoring design step may further include configuring a fault reporting interface for fault reporting upon fault detection in the monitoring component.
  • a computing device includes one or more processors; Memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, a computing device for AUTomotive Open System Architecture (AUTOSAR) based software design, wherein the one or more programs are stored in the memory.
  • the above programs include instructions for defining the structure of software based on the AUTOSAR manual; instructions for analyzing possible defects from the software; and instructions for designing safety monitoring for detecting faults occurring during operation of the software.
  • the embodiment of the present invention it is possible to easily derive the assumed safety requirements even when software development is performed according to the development methodology of AUTOSAR. Through this, it is possible to improve the safety of the developed software to ensure product value, and to prevent possible damage to property and human life while driving a vehicle.
  • FIG. 1 is a block diagram illustrating and describing a computing environment including a computing device suitable for use in exemplary embodiments;
  • FIG. 2 is a flowchart illustrating a design method of AUTOSAR (AUTomotive Open System Architecture)-based software according to an embodiment of the present invention
  • FIG. 3 is a flowchart for explaining a software design step in an embodiment of the present invention.
  • FIG. 5 is a diagram for explaining a state of deriving cause and effect relationship information between a request port and a provision port in a software component in an embodiment of the present invention
  • FIG. 6 is a flowchart illustrating a safety monitoring design step in an embodiment of the present invention.
  • FIG. 1 is a block diagram illustrating and describing a computing environment 10 including a computing device suitable for use in example embodiments.
  • each component may have different functions and capabilities other than those described below, and may include additional components in addition to those described below.
  • the illustrated computing environment 10 includes a computing device 12 .
  • the computing device 12 may be a device for a design method of an AUTomotive Open System Architecture (AUTOSAR) based software according to an embodiment of the present invention.
  • the computing device 12 may include a tool for assisting the software developer in designing the software.
  • AUTOSAR AUTomotive Open System Architecture
  • Computing device 12 includes at least one processor 14 , computer readable storage medium 16 , and communication bus 18 .
  • the processor 14 may cause the computing device 12 to operate in accordance with the exemplary embodiments discussed above.
  • the processor 14 may execute one or more programs stored in the computer-readable storage medium 16 .
  • the one or more programs may include one or more computer-executable instructions that, when executed by the processor 14, configure the computing device 12 to perform operations in accordance with the exemplary embodiment. can be
  • Computer-readable storage medium 16 is configured to store computer-executable instructions or program code, program data, and/or other suitable form of information.
  • the program 20 stored in the computer readable storage medium 16 includes a set of instructions executable by the processor 14 .
  • computer-readable storage medium 16 includes memory (volatile memory, such as random access memory, non-volatile memory, or a suitable combination thereof), one or more magnetic disk storage devices, optical disk storage devices, flash It may be memory devices, other forms of storage medium accessed by computing device 12 and capable of storing desired information, or a suitable combination thereof.
  • Communication bus 18 interconnects various other components of computing device 12 , including processor 14 and computer readable storage medium 16 .
  • Computing device 12 may also include one or more input/output interfaces 22 and one or more network communication interfaces 26 that provide interfaces for one or more input/output devices 24 .
  • the input/output interface 22 and the network communication interface 26 are coupled to the communication bus 18 .
  • Input/output device 24 may be coupled to other components of computing device 12 via input/output interface 22 .
  • Exemplary input/output device 24 may include a pointing device (such as a mouse or trackpad), a keyboard, a touch input device (such as a touchpad or touchscreen), a voice or sound input device, various types of sensor devices, and/or imaging devices. input devices, and/or output devices such as display devices, printers, speakers and/or network cards.
  • the exemplary input/output device 24 may be included in the computing device 12 as a component constituting the computing device 12 , and may be connected to the computing device 12 as a separate device distinct from the computing device 12 . may be
  • the method 200 is a flowchart illustrating a method 200 for designing AUTOSAR (AUTomotive Open System Architecture)-based software according to an embodiment of the present invention.
  • the method 200 may include a method for identifying safety requirements when designing AUTOSAR based software.
  • the method 200 may be performed on a computing device 12 having one or more processors and a memory storing one or more programs to be executed by the one or more processors. To this end, the method 200 may be implemented in the form of a program or software including one or more computer-executable instructions and stored in the memory.
  • the method is described by dividing the method into a plurality of steps, but at least some of the steps are performed in a different order, are performed in combination with other steps, are omitted, or are performed by dividing into detailed steps, or shown. One or more steps not included may be added and performed.
  • the design method 200 reflecting the safety requirements of AUTOSAR-based software includes a software design step 202 defining the structure of the software, a defect analysis step 204 for analyzing possible defects from the software, and the software Safety monitoring design phase 206, which defines a method for detecting faults that occur during operation and reporting the detected faults, and safety requirements refinement phase to reflect the changes if changes occur in safety requirements ( 208) may be included.
  • a software design step 202 defining the structure of the software
  • a defect analysis step 204 for analyzing possible defects from the software includes a defect analysis step 204 for analyzing possible defects from the software.
  • the software Safety monitoring design phase 206 which defines a method for detecting faults that occur during operation and reporting the detected faults, and safety requirements refinement phase to reflect the changes if changes occur in safety requirements ( 208) may be included.
  • safety monitoring design phase 206 which defines a method for detecting faults that occur during operation and reporting the detected faults, and safety requirements refinement phase to reflect the changes if changes occur in safety requirements (
  • FIG. 3 is a flowchart illustrating the software design step 202 in one embodiment of the present invention.
  • the computing device 12 is an interface necessary for realizing a function of software to be designed according to an input of a user (eg, a software developer, etc.) based on the manual (eg, development methodology, etc.) of AUTOSAR. can be defined individually.
  • the interface is an element that specifies a communication method between components, which are unit elements of software.
  • the computing device 12 may configure an interface to specify a defect that may occur in a communication process between components.
  • the computing device 12 may cause problems such as a time out, an inability to process due to excessive requests, an invalid request, an access denied, and a function of the software in the communication process between components. Possible defects can be defined.
  • the computing device 12 may insert an error code for each defect into the interface.
  • an error code for each defect such as a timeout, inability to process due to excessive request (Busy), incorrect request, or access denied (Access Denied) occurs in the communication process between components, the error message for the defect is sent to the other component. To send, you can insert an error code for each fault in the interface.
  • the computing device 12 may define components necessary for realizing a function of software to be designed according to a user input based on the manual of AUTOSAR.
  • Computing device 12 may define one or more components according to software functionality.
  • the computing device 12 may define a port for communication with another component for each component. That is, an interaction between a component and a component is expressed through an interface, and in this case, the mapping element connecting the interface and the component is a port. What data (eg, EVENT, FIELD, METHOD, etc.) is moved through the port may be defined in the interface.
  • the function of the port is determined through the interface, and may be divided into a provided port and a required port according to a communication direction.
  • a provided port may be a port that provides a service
  • a required port may be a port that uses a service.
  • the defect defined in step 302 may include a defect in the provision port and a defect in the request port.
  • a defect in the providing port may mean a defect that can propagate to an external element
  • a defect in the request port may mean a defect that can propagate to an internal element.
  • defects such as timeout, inability to process due to excessive request (Busy), erroneous request, access denied (Access Denied), etc. may occur in the provision port that provides the service, and faults occurring in the provision port may occur.
  • the error code for the service can be transferred from the provision port to the corresponding request port that requested the service.
  • a defect generated from the error code transmitted to the request port may be propagated to a component connected to the request port.
  • the computing device 12 may divide a component (higher-level component) into one or more lower-level components (lower-level components) according to the function of the software to be designed.
  • the computing device 12 may be configured such that the lower component processes input and output to an external element through the port of the upper component.
  • FIG. 4 is a flowchart for explaining the defect analysis step 204 in an embodiment of the present invention.
  • the computing device 12 may derive cause and effect relationship information between the cause of the defect that may occur from the software and the resulting effect based on the software design content.
  • the computing device 12 may set a defect of a request port of a component as a cause and set a defect of a provision port of a component as an influence.
  • the computing device 12 may derive cause and effect relationship information between a request port and a provision port of each component included in software design.
  • FIG. 5 is a diagram for explaining a state of deriving cause and effect relationship information between a request port and a provision port in a software component according to an embodiment of the present invention.
  • the component S10 may include two request ports S11 and S12 and one provision port S13 ( FIG. 5A ).
  • the component S10 may have various division structures according to the configuration of software.
  • the component S10 may be divided into a first sub-component S21 , a second sub-component S22 , and a third sub-component S23 ( FIG. 5B ).
  • the first sub-component S21 may include one request port S21a and one provision port S21b.
  • the request port S21a may have the same configuration as the request port S11 of the component S10 .
  • the second sub-component S22 may include one request port S22a and one provision port S22b.
  • the request port S22a may have the same configuration as the request port S11 of the component S10 .
  • the third sub-component S23 may include one request port S23a and one provision port S23b.
  • the provision port S23b may have the same configuration as the provision port S13 of the component S10 .
  • the provision port S21b of the first sub-component S21 and the provision port S22b of the second sub-component S22 may have the same configuration as the request port S23a of the third sub-component S23. .
  • the component S10 propagates the defect generated due to the defect propagated through the request port S11 and the request port S12 to other components through the provision port S13 . That is, the defects of the request port S11 and the request port S12 act in combination to cause the defect of the component S10 .
  • the defect delivered through the request port S11 is reduced or expanded by the first sub-component S21, and the defect delivered through the request port S12 is reduced or expanded by the second sub-component S21.
  • the failure of the request port S11 and the request port S12 may indirectly act to cause the failure of the component 10 . Accordingly, a more detailed analysis of the cause and effect relationship compared to the component structure of FIG. 5A is possible.
  • the component S10 may be divided into a first sub-component S31 and a second sub-component S32 (FIG. 5(c)).
  • the first sub-component S31 may include one request port S31a and one provision port S31b.
  • the request port S31a may have the same configuration as the request port S11 of the component S10 .
  • the second sub-component S32 may include one request port S32a and one provision port S32b.
  • the request port S32a may have the same configuration as the request port S12 of the component S10 .
  • the provision port S32b may have the same configuration as the provision port S13 of the component S10.
  • the provision port S31b of the first sub-component S31 has the same configuration as the request port S32a of the second sub-component S32, the provision port S31b has the same configuration as the request port S12.
  • the component S10 may be defective due to the indirect action of the request port S11 and the direct action of the request port S12 . Due to this configuration, the defect of the request port (S11) has a relatively small effect compared to the request port (S12).
  • the computing device 12 may create additional information on the derived cause and effect relationship to refine the cause and effect relationship. Specifically, the computing device 12 may assign a level of probability and severity of the defect to each derived cause and effect relationship.
  • the computing device 12 determines the probability of occurrence of a defect and the cause and effect relationship between the request port and the provision port of each component based on the preset importance of each component and the number of times an interaction occurs in each component. A level of severity can be assigned.
  • the computing device 12 may define an action method when a defect occurs according to the level of probability and severity of the defect for each derived cause and effect relationship.
  • the action method may include a defect report, re-execution of software, re-execution of a device loaded with software, change of state of software and a device on which the software is installed, and the like.
  • Table 1 is a table showing the state in which the level of the occurrence probability and severity of a defect is given and the action method is defined for the cause and effect relationship between the request port and the provision port of the component in the embodiment of the present invention.
  • the component S10 may include a request port S11 in which a defect F11 may occur and a request port S12 in which the defects F21 and F22 may occur. It is also assumed that component S10 can generate defects F31 and F32, and can propagate defects F31 and F32 to other components through provision port S13. Then, it is possible to derive the cause and effect relationship between the request port and the provision port as shown in Table 1 for the component S10.
  • the cause and effect relationship may be composed of a combination of possible defects from all request ports and provision ports.
  • the probability and severity of defects are expressed in levels of none (N/A), low (L), medium (M), and high (H), but this is only one example and is not limited thereto. .
  • the computing device 12 may delete those in which the level of the probability of occurrence and severity of a defect among the derived cause and influence relationships is less than a preset reference level.
  • FIG. 6 is a flowchart illustrating the safety monitoring design step 206 in an embodiment of the present invention.
  • the computing device 10 may generate a monitoring component for monitoring a defect occurring during software operation based on the cause and effect relationship information between the request port and the provision port of each component and the action method thereof.
  • the monitoring component may be provided to derive a control flow of data from a cause and effect relationship between a request port and a provision port of each component in the software.
  • the monitoring component may be arranged to insert probes into the source code of the software to identify each node (eg, a component or a port within a component, etc.) within the control flow.
  • the monitoring component can check which nodes the data goes through in the software through the embedded probe.
  • the computing device 10 may include probe insertion information and probe identification information in the monitoring component when generating the monitoring component.
  • the monitoring component may be provided to monitor whether a control flow of data deviates from a preset control flow when the software is operated.
  • the monitoring component monitors whether or not there is a defect by monitoring when a path between nodes of data is different from a preset path and when a required time between a node and a node exceeds a preset required time during operation of the software may be arranged to do so.
  • the computing device 10 may configure a defect reporting interface for defect reporting when the monitoring component detects whether there is a defect. For example, in Table 1, if it is checked whether F11 and F21 are generated from the request port (S11) and the request port (S12), the fault F32 is notified and F11 from the request port (S11) and the provision port (S13)
  • the fault reporting interface can be configured to notify that fault F31 has occurred if it has confirmed that F22 and F22 have occurred.
  • the defect report interface may be assigned to a component in which a defect occurs, and an identifier for defect identification may also be assigned.
  • the safety requirements refinement step 208 may be performed when information on possible defects from a component is changed.
  • the safety requirements refinement step 208 may be configured to redo the software design step 202 , the fault analysis step 204 , and the safety monitoring design step 206 only for the changed faults.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)

Abstract

AUTOSAR 기반의 소프트웨어 설계 방법 및 이를 수행하기 위한 장치를 개시한다. 개시되는 일 실시예에 따른 AUTOSAR 기반의 소프트웨어 설계 방법은, 하나 이상의 프로세서들, 및 하나 이상의 프로세서들에 의해 실행되는 하나 이상의 프로그램들을 저장하는 메모리를 구비한 컴퓨팅 장치에서 수행되는 방법으로서, AUTOSAR(AUTomotive Open System Architecture) 메뉴얼을 기반으로 소프트웨어의 구조를 정의하는 소프트웨어 설계 단계, 설계되는 소프트웨어로부터 발생 가능한 결함을 분석하는 결함 분석 단계, 및 소프트웨어의 동작 중 발생되는 결함을 감지하기 위한 안전 모니터링 설계 단계를 포함한다.

Description

AUTOSAR 기반의 소프트웨어 설계 방법 및 이를 수행하기 위한 장치
본 발명은 개방형 자동차 표준 소프트웨어 아키텍쳐 기술에 관한 것으로, 과학기술정보통신부의 재원으로 지원을 받아 수행된 "지능형 차량서비스를 위한 고신뢰·적응형 전장SW플랫폼 기술 개발"의 연구결과이다.
개방형 자동차 표준 소프트웨어 아키텍쳐(AUTomotive Open System Architecture : AUTOSAR) 기반의 소프트웨어는 차량 내 전자/전기 장치에 탑재되어 동작하는 소프트웨어로, 자동차 기능 안전성 국제 표준(ISO 26262)을 준수하여 개발되어야 한다. 자동차 기능 안전성 국제 표준은 차량 내 안전 관련 전자/전기 장치에 적용되는 표준으로, 전자/전기 장치에 탑재되는 소프트웨어도 그 적용 대상에 포함된다. 자동차 기능 안전성 국제 표준에서 제시하는 기능 안전성을 위한 행위 중에서 가장 중요한 것은 안전 요구사항을 도출하는 것에 있다.
안전 요구사항은 OEM(Original Equipment Manufacturing) 업체로부터 생성되어 전달되는 것이 일반적이지만, 그 적용 대상과 요구 사항이 정해지지 않은 상태로 개발되는 소프트웨어는 안전 요구사항이 존재하지 않는 상황에서 개발이 진행되기도 한다. 자동차 기능 안전성 국제 표준에서는 이와 같은 요소를 SEooC(Safety Element out of Context)로 규정하며, 가정된 안전 요구사항을 정의하여 개발할 것을 권고한다.
그러나 존재하지 않은 안전 요구사항을 새로 정의하는 것은 매우 어려운 작업이다. 개발 소프트웨어만을 대상으로 안전 요구사항을 도출하는 것이 아니라 외부로부터 전파될 수 있는 고장과 외부로 전파될 수 있는 고장을 함께 고려하여야 한다. 또한, 안전 요구사항의 변경도 고려하여야 한다. 실제 소프트웨어의 탑재 과정에서 새로운 안전 요구사항이 도출될 수 있기 때문에, 새로운 안전 요구사항을 쉽게 반영할 수 있도록 통일되고 통용된 방법을 통해 안전 요구사항을 정의 및 관리할 수 있어야 한다.
본 발명은 안전 요구사항을 반영하고 식별할 수 있는 AUTOSAR 기반의 소프트웨어 설계 방법 및 이를 수행하기 위한 장치를 제공하는 것을 목적으로 한다.
한편, 본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명의 일 실시예에 따른 AUTOSAR 기반의 소프트웨어 설계 방법은, 하나 이상의 프로세서들, 및 상기 하나 이상의 프로세서들에 의해 실행되는 하나 이상의 프로그램들을 저장하는 메모리를 구비한 컴퓨팅 장치에서 수행되는 방법으로서, AUTOSAR(AUTomotive Open System Architecture) 메뉴얼을 기반으로 소프트웨어의 구조를 정의하는 소프트웨어 설계 단계; 상기 설계되는 소프트웨어로부터 발생 가능한 결함을 분석하는 결함 분석 단계; 및 상기 소프트웨어의 동작 중 발생되는 결함을 감지하기 위한 안전 모니터링 설계 단계를 포함한다.
상기 소프트웨어 설계 단계는, 상기 AUTOSAR 매뉴얼을 기반으로 사용자의 입력에 따라 상기 소프트웨어의 기능 실현을 위해 필요한 인터페이스를 각각 정의하는 단계; 및 상기 소프트웨어의 기능 실현을 위해 필요한 컴포넌트들을 정의하는 단계를 포함하고, 상기 인터페이스를 각각 정의하는 단계는, 상기 컴포넌트 간 통신 과정에서 발생될 수 있는 결함을 명시하도록 하는 단계를 포함할 수 있다.
상기 컴포넌트들을 정의하는 단계는, 각 컴포넌트들에 대해 다른 컴포넌트와의 통신을 위한 제공 포트 및 요구 포트를 정의하는 단계를 포함하고, 상기 인터페이스를 각각 정의하는 단계는, 상기 제공 포트 및 상기 요구 포트에서 발생될 수 있는 결함을 명시하도록 하는 단계를 포함할 수 있다.
상기 결함 분석 단계는, 상기 소프트웨어로부터 발생 가능한 결함의 원인 및 그로 인한 영향 간에 원인 및 영향 관계를 도출하는 단계를 포함할 수 있다.
상기 원인 및 영향 관계를 도출하는 단계는, 상기 컴포넌트의 요구 포트의 결함을 원인으로 설정하고, 상기 컴포넌트의 제공 포트의 결함을 영향으로 설정하여 상기 소프트웨어에 포함된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계를 도출할 수 있다.
상기 결함 분석 단계는, 상기 도출된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계에 대해 결함의 발생 가능성 및 심각성 정도 중 하나 이상에 대해 레벨을 부여하는 단계; 및 상기 부여된 레벨에 따라 상기 도출된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계에 대해 결함 발생 시 조치 방법을 정의하는 단계를 더 포함할 수 있다.
상기 레벨을 부여하는 단계는, 기 설정된 각 컴포넌트의 중요도 및 각 컴포넌트에서 인터랙션이 발생되는 횟수를 기반으로 상기 원인 및 영향 관계에 대해 레벨을 부여할 수 있다.
상기 결함 분석 단계는, 상기 도출된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계들 중 상기 레벨이 기 설정된 기준 레벨 미만인 것은 삭제하는 단계를 더 포함할 수 있다.
상기 안전 모니터링 설계 단계는, 상기 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계와 상기 조치 방법을 기반으로 상기 소프트웨어 동작시 발생하는 결함을 모니터링하기 위한 감시 컴포넌트를 생성하는 단계를 포함할 수 있다.
상기 감시 컴포넌트는, 상기 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계로부터 상기 소프트웨어 내의 데이터 제어 흐름을 도출할 수 있도록 마련될 수 있다.
상기 안전 모니터링 설계 단계는, 상기 감시 컴포넌트에서 결함 감지 시 결함 보고를 위한 결함 보고 인터페이스를 구성하는 단계를 더 포함할 수 있다.
본 발명의 일 실시예에 따른 컴퓨팅 장치는, 하나 이상의 프로세서들; 메모리; 및 하나 이상의 프로그램들을 포함하고, 상기 하나 이상의 프로그램들은 상기 메모리에 저장되고, 상기 하나 이상의 프로세서들에 의해 실행되도록 구성되고, AUTOSAR(AUTomotive Open System Architecture) 기반의 소프트웨어 설계를 위한 컴퓨팅 장치로서, 상기 하나 이상의 프로그램들은, AUTOSAR 메뉴얼을 기반으로 소프트웨어의 구조를 정의하기 위한 명령; 상기 소프트웨어로부터 발생 가능한 결함을 분석하기 위한 명령; 및 상기 소프트웨어의 동작 중 발생되는 결함을 감지하기 위한 안전 모니터링을 설계하기 위한 명령을 포함한다.
본 발명의 실시예에 따르면, AUTOSAR의 개발 방법론에 따라 소프트웨어의 개발을 수행하더라도 가정된 안전 요구사항을 용이하게 도출할 수 있게 된다. 이를 통해 개발되는 소프트웨어의 안전성을 향상시켜 상품 가치를 보장할 수 있도록 하며, 자동차 주행 중 발생 가능한 재산 및 인명 피해를 예방할 수 있게 된다.
또한, 소프트웨어로부터 발생 가능한 결함을 개발자가 미리 인지하도록 함으로써 방어적 프로그래밍(Defensive Programming)이 가능하도록 하며 검증 케이스를 쉽게 식별할 수 있도록 도와 줄 수 있다. 그로 인해, 개발되는 소프트웨어의 신뢰성을 보장할 수 있게 된다.
한편, 본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 예시적인 실시예들에서 사용되기에 적합한 컴퓨팅 장치를 포함하는 컴퓨팅 환경을 예시하여 설명하기 위한 블록도이고,
도 2는 본 발명의 일 실시예에 따른 AUTOSAR(AUTomotive Open System Architecture) 기반 소프트웨어의 설계 방법을 설명하기 위한 흐름도이고,
도 3은 본 발명의 일 실시예에서 소프트웨어 설계 단계를 설명하기 위한 흐름도이고,
도 4는 본 발명의 일 실시예에서 결함 분석 단계를 설명하기 위한 흐름도이고,
도 5는 본 발명의 일 실시예에서 소프트웨어의 컴포넌트에서 요구 포트와 제공 포트 간의 원인 및 영향 관계 정보를 도출하는 상태를 설명하기 위한 도면이고,
도 6은 본 발명의 일 실시예에서 안전 모니터링 설계 단계를 설명하기 위한 흐름도이다.
이하, 본 발명의 실시 예를 첨부된 도면들을 참조하여 더욱 상세하게 설명한다. 본 발명의 실시 예는 여러 가지 형태로 변형할 수 있으며, 본 발명의 범위가 아래의 실시 예들로 한정되는 것으로 해석되어서는 안 된다. 본 실시 예는 당업계에서 평균적인 지식을 가진 자에게 본 발명을 더욱 완전하게 설명하기 위해 제공되는 것이다. 따라서 도면에서의 요소의 형상은 보다 명확한 설명을 강조하기 위해 과장되었다.
본 발명이 해결하고자 하는 과제의 해결 방안을 명확하게 하기 위한 발명의 구성을 본 발명의 바람직한 실시 예에 근거하여 첨부 도면을 참조하여 상세히 설명하되, 도면의 구성요소들에 참조번호를 부여함에 있어서 동일 구성요소에 대해서는 비록 다른 도면상에 있더라도 동일 참조번호를 부여하였으며 당해 도면에 대한 설명 시 필요한 경우 다른 도면의 구성요소를 인용할 수 있음을 미리 밝혀둔다.
도 1은 예시적인 실시예들에서 사용되기에 적합한 컴퓨팅 장치를 포함하는 컴퓨팅 환경(10)을 예시하여 설명하기 위한 블록도이다. 도시된 실시예에서, 각 컴포넌트들은 이하에 기술된 것 이외에 상이한 기능 및 능력을 가질 수 있고, 이하에 기술된 것 이외에도 추가적인 컴포넌트를 포함할 수 있다.
도시된 컴퓨팅 환경(10)은 컴퓨팅 장치(12)를 포함한다. 일 실시예에서, 컴퓨팅 장치(12)는 본 발명의 실시예에 따른 AUTOSAR(AUTomotive Open System Architecture) 기반 소프트웨어의 설계 방법을 위한 장치일 수 있다. 여기서, 컴퓨팅 장치(12)는 소프트웨어 개발자가 소프트웨어 설계 시 이를 보조하기 위한 도구(Tool)를 포함할 수 있다.
컴퓨팅 장치(12)는 적어도 하나의 프로세서(14), 컴퓨터 판독 가능 저장 매체(16) 및 통신 버스(18)를 포함한다. 프로세서(14)는 컴퓨팅 장치(12)로 하여금 앞서 언급된 예시적인 실시예에 따라 동작하도록 할 수 있다. 예컨대, 프로세서(14)는 컴퓨터 판독 가능 저장 매체(16)에 저장된 하나 이상의 프로그램들을 실행할 수 있다. 상기 하나 이상의 프로그램들은 하나 이상의 컴퓨터 실행 가능 명령어를 포함할 수 있으며, 상기 컴퓨터 실행 가능 명령어는 프로세서(14)에 의해 실행되는 경우 컴퓨팅 장치(12)로 하여금 예시적인 실시예에 따른 동작들을 수행하도록 구성될 수 있다.
컴퓨터 판독 가능 저장 매체(16)는 컴퓨터 실행 가능 명령어 내지 프로그램 코드, 프로그램 데이터 및/또는 다른 적합한 형태의 정보를 저장하도록 구성된다. 컴퓨터 판독 가능 저장 매체(16)에 저장된 프로그램(20)은 프로세서(14)에 의해 실행 가능한 명령어의 집합을 포함한다. 일 실시예에서, 컴퓨터 판독 가능 저장 매체(16)는 메모리(랜덤 액세스 메모리와 같은 휘발성 메모리, 비휘발성 메모리, 또는 이들의 적절한 조합), 하나 이상의 자기 디스크 저장 디바이스들, 광학 디스크 저장 디바이스들, 플래시 메모리 디바이스들, 그 밖에 컴퓨팅 장치(12)에 의해 액세스되고 원하는 정보를 저장할 수 있는 다른 형태의 저장 매체, 또는 이들의 적합한 조합일 수 있다.
통신 버스(18)는 프로세서(14), 컴퓨터 판독 가능 저장 매체(16)를 포함하여 컴퓨팅 장치(12)의 다른 다양한 컴포넌트들을 상호 연결한다.
컴퓨팅 장치(12)는 또한 하나 이상의 입출력 장치(24)를 위한 인터페이스를 제공하는 하나 이상의 입출력 인터페이스(22) 및 하나 이상의 네트워크 통신 인터페이스(26)를 포함할 수 있다. 입출력 인터페이스(22) 및 네트워크 통신 인터페이스(26)는 통신 버스(18)에 연결된다. 입출력 장치(24)는 입출력 인터페이스(22)를 통해 컴퓨팅 장치(12)의 다른 컴포넌트들에 연결될 수 있다. 예시적인 입출력 장치(24)는 포인팅 장치(마우스 또는 트랙패드 등), 키보드, 터치 입력 장치(터치패드 또는 터치스크린 등), 음성 또는 소리 입력 장치, 다양한 종류의 센서 장치 및/또는 촬영 장치와 같은 입력 장치, 및/또는 디스플레이 장치, 프린터, 스피커 및/또는 네트워크 카드와 같은 출력 장치를 포함할 수 있다. 예시적인 입출력 장치(24)는 컴퓨팅 장치(12)를 구성하는 일 컴포넌트로서 컴퓨팅 장치(12)의 내부에 포함될 수도 있고, 컴퓨팅 장치(12)와는 구별되는 별개의 장치로 컴퓨팅 장치(12)와 연결될 수도 있다.
도 2는 본 발명의 일 실시예에 따른 AUTOSAR(AUTomotive Open System Architecture) 기반 소프트웨어의 설계 방법(200)을 설명하기 위한 흐름도이다. 상기 방법(200)은 AUTOSAR 기반 소프트웨어 설계 시 안전 요구 사항을 식별하기 위한 방법을 포함할 수 있다.
상기 방법(200)은 하나 이상의 프로세서들, 및 하나 이상의 프로세서들에 의해 실행되는 하나 이상의 프로그램들을 저장하는 메모리를 구비한 컴퓨팅 장치(12)에서 수행될 수 있다. 이를 위하여, 상기 방법(200)은 하나 이상의 컴퓨터 실행 가능 명령어를 포함하는 프로그램 내지 소프트웨어의 형태로 구현되어 상기 메모리상에 저장될 수 있다.
또한, 도시된 흐름도에서는 상기 방법을 복수 개의 단계로 나누어 기재하였으나, 적어도 일부의 단계들은 순서를 바꾸어 수행되거나, 다른 단계와 결합되어 함께 수행되거나, 생략되거나, 세부 단계들로 나뉘어 수행되거나, 또는 도시되지 않은 하나 이상의 단계가 부가되어 수행될 수 있다.
도 2를 참조하면, AUTOSAR 기반 소프트웨어의 안전 요구 사항을 반영한 설계 방법(200)은 소프트웨어의 구조를 정의하는 소프트웨어 설계 단계(202), 소프트웨어로부터 발생 가능한 결함을 분석하는 결함 분석 단계(204), 소프트웨어의 동작 중 발생된 결함을 감지하고 감지된 결함을 보고하기 위한 방법을 정의하는 안전 모니터링 설계 단계(206), 및 안전 요구사항에 변경이 발생하는 경우 변경된 사항을 반영하기 위한 안전 요구사항 정제 단계(208)를 포함할 수 있다. 이하, 각 단계에 대해 상세히 살펴보기로 한다.
도 3은 본 발명의 일 실시예에서 소프트웨어 설계 단계(202)를 설명하기 위한 흐름도이다.
단계 302에서, 컴퓨팅 장치(12)는 AUTOSAR의 매뉴얼(예를 들어, 개발 방법론 등)을 기반으로 사용자(예를 들어, 소프트웨어 개발자 등)의 입력에 따라 설계하고자 하는 소프트웨어의 기능 실현을 위해 필요한 인터페이스를 각각 정의할 수 있다. 여기서, 인터페이스는 소프트웨어의 단위 요소인 컴포넌트 사이의 통신 방법을 명시한 요소이다.
컴퓨팅 장치(12)는 컴포넌트 간 통신 과정에서 발생될 수 있는 결함에 대해 명시하도록 인터페이스를 구성할 수 있다. 예시적인 실시예에서, 컴퓨팅 장치(12)는 컴포넌트 간 통신 과정에서 시간 초과(Time out), 요청 과다로 인한 처리 불능(Busy), 잘못된 요청, 접근 거부(Access Denied), 및 소프트웨어의 기능 등으로 인해 발생 가능한 결함을 정의할 수 있다.
이때, 컴퓨팅 장치(12)는 인터페이스에 각 결함에 대한 에러 코드가 삽입되도록 할 수 있다. 즉, 컴포넌트 간 통신 과정에서 시간 초과(Time out), 요청 과다로 인한 처리 불능(Busy), 잘못된 요청, 접근 거부(Access Denied) 등과 같은 결함이 발생한 경우, 해당 결함에 대한 에러 메시지를 상대 컴포넌트로 보내기 위해, 인터페이스에 각 결함에 대한 에러 코드를 삽입할 수 있다.
단계 304에서, 컴퓨팅 장치(12)는 AUTOSAR의 매뉴얼을 기반으로 사용자의 입력에 따라 설계하고자 하는 소프트웨어의 기능 실현을 위해 필요한 컴포넌트들을 정의할 수 있다. 컴퓨팅 장치(12)는 소프트웨어 기능에 따라 하나 이상의 컴포넌트를 정의할 수 있다.
컴퓨팅 장치(12)는 각 컴포넌트에 대해 다른 컴포넌트와의 통신을 위한 포트(Port)를 정의할 수 있다. 즉, 컴포넌트와 컴포넌트 간 인터랙션은 인터페이스를 통해 표현되는데, 이때 인터페이스와 컴포넌트를 연결하는 매핑 요소가 포트이다. 포트를 통해 어떤 데이터(예를 들어, EVENT, FIELD, METHOD 등)가 이동되는지에 대해서는 인터페이스에 정의될 수 있다.
여기서, 포트는 인터페이스를 통해 그 기능이 결정되며, 통신 방향에 따라 제공 포트(Provided Port)와 요구 포트(Required Port)로 구분될 수 있다. 제공 포트(Provided Port)는 서비스를 제공하는 포트이고, 요구 포트(Required Port)는 서비스를 사용하는 포트일 수 있다.
한편, 단계 302에서 정의된 결함에는 제공 포트의 결함 및 요구 포트의 결함을 포함할 수 있다. 제공 포트의 결함은 외부 요소로 전파될 수 있는 결함을 의미하고, 요구 포트의 결함은 내부 요소로 전파될 수 있는 결함을 의미할 수 있다.
즉, 시간 초과(Time out), 요청 과다로 인한 처리 불능(Busy), 잘못된 요청, 접근 거부(Access Denied) 등과 같은 결함은 서비스를 제공하는 제공 포트에서 발생할 수 있으며, 제공 포트에서 발생된 결함에 대한 에러 코드는 제공 포트로부터 서비스를 요구한 해당 요구 포트로 전달될 수 있다. 그리고, 요구 포트에 전달된 에러 코드로부터 발생된 결함은 요구 포트에 연결된 컴포넌트로 전파될 수 있다.
단계 306에서, 컴퓨팅 장치(12)는 설계하고자 하는 소프트웨어의 기능에 따라 컴포넌트(상위 컴포넌트)를 하나 이상의 하위 구조의 컴포넌트(하위 컴포넌트)로 분할 할 수 있다. 여기서, 컴퓨팅 장치(12)는 하위 컴포넌트가 상위 컴포넌트의 포트를 통해 외부 요소로 입력과 출력을 처리하도록 구성할 수 있다.
도 4는 본 발명의 일 실시예에서 결함 분석 단계(204)를 설명하기 위한 흐름도이다.
단계 402에서, 컴퓨팅 장치(12)는 소프트웨어 설계 내용을 기반으로 소프트웨어로부터 발생 가능한 결함의 원인 및 그로 인한 영향 간에 원인 및 영향 관계 정보를 도출할 수 있다. 컴퓨팅 장치(12)는 원인 및 영향 관계 정보를 도출하기 위해, 컴포넌트의 요구 포트의 결함을 원인으로 설정하고, 컴포넌트의 제공 포트의 결함을 영향으로 설정할 수 있다. 컴퓨팅 장치(12)는 소프트웨어 설계 시 포함된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계 정보를 도출할 수 있다.
도 5는 본 발명의 일 실시예에서 소프트웨어의 컴포넌트에서 요구 포트와 제공 포트 간의 원인 및 영향 관계 정보를 도출하는 상태를 설명하기 위한 도면이다.
도 5를 참조하면, 컴포넌트(S10)는 두 개의 요구 포트(S11, S12)와 한 개의 제공 포트(S13)로 구성될 수 있다(도 5의 (a)). 컴포넌트(S10)은 소프트웨어의 구성에 따라 다양한 분할 구조를 가질 수 있다. 예시적인 실시예에서, 컴포넌트(S10)는 제1 하위 컴포넌트(S21), 제2 하위 컴포넌트(S22), 및 제3 하위 컴포넌트(S23)로 분할 될 수 있다(도 5의 (b)).
여기서, 제1 하위 컴포넌트(S21)는 하나의 요구 포트(S21a)와 하나의 제공 포트(S21b)로 구성될 수 있다. 이때, 요구 포트(S21a)는 컴포넌트(S10)의 요구 포트(S11)와 동일한 구성을 가질 수 있다. 제2 하위 컴포넌트(S22)는 하나의 요구 포트(S22a)와 하나의 제공 포트(S22b)로 구성될 수 있다. 이때, 요구 포트(S22a)는 컴포넌트(S10)의 요구 포트(S11)와 동일한 구성을 가질 수 있다.
제3 하위 컴포넌트(S23)는 하나의 요구 포트(S23a)와 하나의 제공 포트(S23b)로 구성될 수 있다. 이때, 제공 포트(S23b)는 컴포넌트(S10)의 제공 포트(S13)와 동일한 구성을 가질 수 있다. 또한, 제1 하위 컴포넌트(S21)의 제공 포트(S21b) 및 제2 하위 컴포넌트(S22)의 제공 포트(S22b)는 제3 하위 컴포넌트(S23)의 요구 포트(S23a)와 동일한 구성을 가질 수 있다.
도 5의 (a)에서 컴포넌트(S10)는 요구 포트(S11)과 요구 포트(S12)를 통해 전파된 결함이 원인이 되어서 발생된 결함을 제공 포트(S13)를 통해 다른 컴포넌트에 전파하게 된다. 즉, 요구 포트(S11)과 요구 포트(S12)의 결함이 복합적으로 작용하여 컴포넌트(S10)의 결함을 발생시킬 수 있게 된다.
도 5의 (b)에서도 동일한 방식으로 원인 및 영향 관계를 가지게 된다. 다만, 요구 포트(S11)을 통해 전달된 결함은 제1 하위 컴포넌트(S21)에 의해 축소 또는 확장되고, 요구 포트(S12)를 통해 전달된 결함은 제2 하위 컴포넌트(S21)에 의해 축소 또는 확장될 수 있다. 즉, 요구 포트(S11)와 요구 포트(S12)의 결함이 간접적으로 작용하여 컴포넌트(10)의 결함을 발생시킬 수 있게 된다. 이에 따라, 도 5의 (a)의 컴포넌트 구조에 비해 더 상세한 원인 및 영향 관계 분석이 가능하게 된다.
한편, 예시적인 다른 실시예에서, 컴포넌트(S10)는 제1 하위 컴포넌트(S31) 및 제2 하위 컴포넌트(S32)로 분할 될 수 있다(도 5의 (c)).
여기서, 제1 하위 컴포넌트(S31)는 하나의 요구 포트(S31a)와 하나의 제공 포트(S31b)로 구성될 수 있다. 이때, 요구 포트(S31a)는 컴포넌트(S10)의 요구 포트(S11)와 동일한 구성을 가질 수 있다.
제2 하위 컴포넌트(S32)는 하나의 요구 포트(S32a)와 하나의 제공 포트(S32b)로 구성될 수 있다. 이때, 요구 포트(S32a)는 컴포넌트(S10)의 요구 포트(S12)와 동일한 구성을 가질 수 있다. 그리고, 제공 포트(S32b)는 컴포넌트(S10)의 제공 포트(S13)와 동일한 구성을 가질 수 있다. 또한, 제1 하위 컴포넌트(S31)의 제공 포트(S31b)는 제2 하위 컴포넌트(S32)의 요구 포트(S32a)와 동일한 구성을 가지므로, 제공 포트(S31b)는 요구 포트(S12)와 동일한 구성을 가지게 된다.
도 5의 (c)에서 컴포넌트(S10)는 요구 포트(S11)의 간접적 작용과 요구 포트(S12)의 직접적 작용으로 인해 결함이 발생할 수 있다. 이러한 구성으로 인해, 요구 포트(S11)의 결함은 요구 포트(S12)에 비해 상대적으로 적은 영향을 미치게 된다.
다시 도 4를 참조하면, 단계 404에서, 컴퓨팅 장치(12)는 도출된 원인 및 영향 관계에 대해 추가 정보를 작성하여 원인 및 영향 관계를 상세화 할 수 있다. 구체적으로, 컴퓨팅 장치(12)는 도출된 각 원인 및 영향 관계에 대해 결함의 발생 가능성 및 심각성 정도의 레벨을 부여할 수 있다.
예시적인 실시예에서, 컴퓨팅 장치(12)는 기 설정된 각 컴포넌트의 중요도 및 각 컴포넌트에서 인터랙션이 발생되는 횟수를 기반으로 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계에 대해 결함의 발생 가능성 및 심각성 정도의 레벨을 부여할 수 있다.
단계 406에서, 컴퓨팅 장치(12)는 도출된 각 원인 및 영향 관계에 대해 결함의 발생 가능성 및 심각성 정도의 레벨에 따라 결함 발생 시 조치 방법을 정의할 수 있다. 예시적인 실시예에서, 조치 방법으로는 결함 보고, 소프트웨어 재실행, 소프트웨어가 탑재된 장치 재실행, 소프트웨어 및 소프트웨어가 탑재된 장치의 상태 변경 등이 포함될 수 있다.
표 1은 본 발명의 실시예에서 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계에 대해 결함의 발생 가능성 및 심각성 정도의 레벨을 부여하고 조치 방법을 정의한 상태를 나타낸 표이다.
원인 영향 발생 가능성 심각도 조치 방법
F11×F21 F31 N/A N/A N/A
F11×F22 F31 L H 재실행
F11×F21 F32 M L 보고
F11×F22 F32 N/A N/A N/A
표 1을 참조하면, 도 5의 (a)에서 컴포넌트(S10)가 결함 F11이 발생 가능한 요구 포트(S11)와 결함 F21 및 F22가 발생 가능한 요구 포트(S 12)를 포함할 수 있다. 또한, 컴포넌트(S10)는 결함 F31 및 F32를 발생시킬 수 있으며, 결함 F31 및 F32를 제공 포트(S13)을 통해 다른 컴포넌트로 전파 할 수 있다고 가정한다. 그러면, 컴포넌트(S10)에 대해 표 1과 같은 요구 포트와 제공 포트 간 원인 및 영향 관계를 도출할 수 있다. 여기서, 원인 및 영향 관계는 모든 요구 포트와 제공 포트로부터 발생 가능한 결함의 조합으로 구성될 수 있다. 표 1에서는 결함의 발생 가능성 및 심각도를 없음(N/A), 낮음(L), 중간(M), 및 높음(H)의 레벨로 표현하였으나, 이는 하나의 실시예일 뿐이며, 이에 한정되는 것은 아니다.
표 1에서, 요구 포트와 제공 포트 간 원인 및 영향 관계들 중 F11×F21 → F31와 F11×F22 → F32에 대해 결함의 발생 가능성이 없음(N/A)으로 표현된 것은 모든 포트는 동시에 하나의 결함만을 발생시킬 수 있으므로, F11×F21 → F31와 F11×F22 → F32은 컴포넌트 구조 상 발생할 수 없기 때문이다.
한편, 컴퓨팅 장치(12)는 도출된 각 원인 및 영향 관계들 중 결함의 발생 가능성 및 심각성 정도의 레벨이 기 설정된 기준 레벨 미만인 것은 삭제할 수 있다.
도 6은 본 발명의 일 실시예에서 안전 모니터링 설계 단계(206)를 설명하기 위한 흐름도이다.
단계 602에서, 컴퓨팅 장치(10)는 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계 정보와 그 조치 방법을 기반으로 소프트웨어 동작시 발생하는 결함을 모니터링하기 위한 감시 컴포넌트를 생성할 수 있다.
여기서, 감시 컴포넌트는 소프트웨어 내의 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계로부터 데이터의 제어 흐름(Control Flow)을 도출할 수 있도록 마련될 수 있다. 감시 컴포넌트는 제어 흐름 내에서 각 노드(예를 들어, 컴포넌트 또는 컴포넌트 내의 포트 등)를 식별하기 위해 소프트웨어의 소스코드에 프로브를 삽입하도록 마련될 수 있다. 감시 컴포넌트는 삽입된 프로브를 통해 데이터가 소프트웨어 내에서 어떤 노드들을 거치는지 확인할 수 있게 된다. 컴퓨팅 장치(10)는 감시 컴포넌트 생성 시 프로브 삽입 정보 및 프로브 식별 정보를 감시 컴포넌트에 포함시킬 수 있다.
감시 컴포넌트는 소프트웨어의 동작 시 데이터의 제어 흐름이 기 설정된 제어 흐름을 벗어나는지 감시하도록 마련될 수 있다. 예시적인 실시예에서, 감시 컴포넌트는 소프트웨어의 동작 시 데이터의 노드들 간의 경로가 기 설정된 경로와 다른 경우 및 노드와 노드 간 소요 시간이 기 설정된 소요 시간을 초과하는 경우 등을 감시하여 결함 여부를 모니터링하도록 마련될 수 있다.
단계 604에서, 컴퓨팅 장치(10)는 감시 컴포넌트에서 결함 여부를 검출하는 경우, 결함 보고를 위한 결함 보고 인터페이스를 구성할 수 있다. 예를 들어, 표 1에서 요구 포트(S11)과 요구 포트(S12)로부터 F11과 F21의 발생 여부를 확인한 경우 결함 F32가 발생했음을 알리도록 하고, 요구 포트(S11)과 제공 포트(S13)으로부터 F11과 F22의 발생 여부를 확인한 경우 결함 F31이 발생했음을 알리도록 결함 보고 인터페이스를 구성할 수 있다. 이때, 결함 보고 인터페이스는 결함이 발생되는 컴포넌트에 할당될 수 있으며, 결함 식별을 위한 식별자도 함께 배정될 수 있다.
한편, 다시 도 2를 참조하면, 안전 요구사항 정제 단계(208)는 컴포넌트로부터 발생 가능한 결함 정보가 변경되는 경우 수행될 수 있다. 안전 요구사항 정제 단계(208)는 변경된 결함에 한하여 소프트웨어 설계 단계(202), 결함 분석 단계(204), 및 안전 모니터링 설계 단계(206)를 재수행하도록 구성될 수 있다.
개시되는 실시예에 의하면, AUTOSAR의 개발 방법론에 따라 소프트웨어의 개발을 수행하더라도 가정된 안전 요구사항을 용이하게 도출할 수 있게 된다. 이를 통해 개발되는 소프트웨어의 안전성을 향상시켜 상품 가치를 보장할 수 있도록 하며, 자동차 주행 중 발생 가능한 재산 및 인명 피해를 예방할 수 있게 된다.
또한, 소프트웨어로부터 발생 가능한 결함을 개발자가 미리 인지하도록 함으로써 방어적 프로그래밍(Defensive Programming)이 가능하도록 하며 검증 케이스를 쉽게 식별할 수 있도록 도와 줄 수 있다. 그로 인해, 개발되는 소프트웨어의 신뢰성을 보장할 수 있게 된다.
이상의 상세한 설명은 본 발명을 예시하는 것이다. 또한 전술한 내용은 본 발명의 바람직한 실시 형태를 나타내어 설명하는 것이며, 본 발명은 다양한 다른 조합, 변경 및 환경에서 사용할 수 있다. 즉 본 명세서에 개시된 발명의 개념의 범위, 저술한 개시 내용과 균등한 범위 및/또는 당업계의 기술 또는 지식의 범위내에서 변경 또는 수정이 가능하다. 저술한 실시예는 본 발명의 기술적 사상을 구현하기 위한 최선의 상태를 설명하는 것이며, 본 발명의 구체적인 적용 분야 및 용도에서 요구되는 다양한 변경도 가능하다. 따라서 이상의 발명의 상세한 설명은 개시된 실시 상태로 본 발명을 제한하려는 의도가 아니다. 또한 첨부된 청구범위는 다른 실시 상태도 포함하는 것으로 해석되어야 한다.

Claims (12)

  1. 하나 이상의 프로세서들, 및
    상기 하나 이상의 프로세서들에 의해 실행되는 하나 이상의 프로그램들을 저장하는 메모리를 구비한 컴퓨팅 장치에서 수행되는 방법으로서,
    AUTOSAR(AUTomotive Open System Architecture) 메뉴얼을 기반으로 소프트웨어의 구조를 정의하는 소프트웨어 설계 단계;
    상기 설계되는 소프트웨어로부터 발생 가능한 결함을 분석하는 결함 분석 단계; 및
    상기 소프트웨어의 동작 중 발생되는 결함을 감지하기 위한 안전 모니터링 설계 단계를 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
  2. 청구항 1에 있어서,
    상기 소프트웨어 설계 단계는,
    상기 AUTOSAR 매뉴얼을 기반으로 사용자의 입력에 따라 상기 소프트웨어의 기능 실현을 위해 필요한 인터페이스를 각각 정의하는 단계; 및
    상기 소프트웨어의 기능 실현을 위해 필요한 컴포넌트들을 정의하는 단계를 포함하고,
    상기 인터페이스를 각각 정의하는 단계는, 상기 컴포넌트 간 통신 과정에서 발생될 수 있는 결함을 명시하도록 하는 단계를 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
  3. 청구항 2에 있어서,
    상기 컴포넌트들을 정의하는 단계는, 각 컴포넌트들에 대해 다른 컴포넌트와의 통신을 위한 제공 포트 및 요구 포트를 정의하는 단계를 포함하고,
    상기 인터페이스를 각각 정의하는 단계는, 상기 제공 포트 및 상기 요구 포트에서 발생될 수 있는 결함을 명시하도록 하는 단계를 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
  4. 청구항 3에 있어서,
    상기 결함 분석 단계는,
    상기 소프트웨어로부터 발생 가능한 결함의 원인 및 그로 인한 영향 간에 원인 및 영향 관계를 도출하는 단계를 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
  5. 청구항 4에 있어서,
    상기 원인 및 영향 관계를 도출하는 단계는,
    상기 컴포넌트의 요구 포트의 결함을 원인으로 설정하고, 상기 컴포넌트의 제공 포트의 결함을 영향으로 설정하여 상기 소프트웨어에 포함된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계를 도출하는, AUTOSAR 기반의 소프트웨어 설계 방법.
  6. 청구항 5에 있어서,
    상기 결함 분석 단계는,
    상기 도출된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계에 대해 결함의 발생 가능성 및 심각성 정도 중 하나 이상에 대해 레벨을 부여하는 단계; 및
    상기 부여된 레벨에 따라 상기 도출된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계에 대해 결함 발생 시 조치 방법을 정의하는 단계를 더 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
  7. 청구항 6에 있어서,
    상기 레벨을 부여하는 단계는,
    기 설정된 각 컴포넌트의 중요도 및 각 컴포넌트에서 인터랙션이 발생되는 횟수를 기반으로 상기 원인 및 영향 관계에 대해 레벨을 부여하는, AUTOSAR 기반의 소프트웨어 설계 방법.
  8. 청구항 6에 있어서,
    상기 결함 분석 단계는,
    상기 도출된 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계들 중 상기 레벨이 기 설정된 기준 레벨 미만인 것은 삭제하는 단계를 더 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
  9. 청구항 6에 있어서,
    상기 안전 모니터링 설계 단계는,
    상기 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계와 상기 조치 방법을 기반으로 상기 소프트웨어 동작시 발생하는 결함을 모니터링하기 위한 감시 컴포넌트를 생성하는 단계를 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
  10. 청구항 9에 있어서,
    상기 감시 컴포넌트는,
    상기 각 컴포넌트의 요구 포트와 제공 포트 간의 원인 및 영향 관계로부터 상기 소프트웨어 내의 데이터 제어 흐름을 도출할 수 있도록 마련되는, AUTOSAR 기반의 소프트웨어 설계 방법.
  11. 청구항 9에 있어서,
    상기 안전 모니터링 설계 단계는,
    상기 감시 컴포넌트에서 결함 감지 시 결함 보고를 위한 결함 보고 인터페이스를 구성하는 단계를 더 포함하는, AUTOSAR 기반의 소프트웨어 설계 방법.
  12. 하나 이상의 프로세서들;
    메모리; 및
    하나 이상의 프로그램들을 포함하고,
    상기 하나 이상의 프로그램들은 상기 메모리에 저장되고, 상기 하나 이상의 프로세서들에 의해 실행되도록 구성되고, AUTOSAR(AUTomotive Open System Architecture) 기반의 소프트웨어 설계를 위한 컴퓨팅 장치로서,
    상기 하나 이상의 프로그램들은,
    AUTOSAR 메뉴얼을 기반으로 소프트웨어의 구조를 정의하기 위한 명령;
    상기 소프트웨어로부터 발생 가능한 결함을 분석하기 위한 명령; 및
    상기 소프트웨어의 동작 중 발생되는 결함을 감지하기 위한 안전 모니터링을 설계하기 위한 명령을 포함하는, 컴퓨팅 장치.
PCT/KR2019/016473 2019-11-27 2019-11-27 Autosar 기반의 소프트웨어 설계 방법 및 이를 수행하기 위한 장치 WO2021107183A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2019-0153876 2019-11-27
KR1020190153876A KR20210065301A (ko) 2019-11-27 2019-11-27 Autosar 기반의 소프트웨어 설계 방법 및 이를 수행하기 위한 장치

Publications (1)

Publication Number Publication Date
WO2021107183A1 true WO2021107183A1 (ko) 2021-06-03

Family

ID=76130613

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/016473 WO2021107183A1 (ko) 2019-11-27 2019-11-27 Autosar 기반의 소프트웨어 설계 방법 및 이를 수행하기 위한 장치

Country Status (2)

Country Link
KR (1) KR20210065301A (ko)
WO (1) WO2021107183A1 (ko)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102630360B1 (ko) * 2021-12-27 2024-01-29 주식회사 알티스트 Autosar 센서 인터페이스의 정적 설정 시스템 및 방법
KR102600294B1 (ko) * 2021-12-29 2023-11-09 주식회사 알티스트 차량용 플랫폼을 위한 arinc 기반 운영체제 헬스 모니터링 설정 코드 자동 생성 장치 및 방법
KR102545640B1 (ko) * 2022-01-04 2023-06-20 주식회사 알티스트 철도차량 시스템의 소프트웨어 개발 시스템 및 방법

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101134735B1 (ko) * 2010-11-03 2012-04-13 재단법인대구경북과학기술원 소프트웨어 컴포넌트 설계정보를 이용한 소프트웨어 테스트 방법 및 시스템
US20140019942A1 (en) * 2012-07-10 2014-01-16 Dspace Digital Signal Processing And Control Engineering Gmbh Method and device for creating and testing a control unit program
KR20180014978A (ko) * 2016-08-02 2018-02-12 (주)씽크포비엘 전장용 소프트웨어 안전성 분석 방법 및 장치
KR20180078697A (ko) * 2016-12-30 2018-07-10 경북대학교 산학협력단 차량용 소프트웨어 테스트 방법
KR20190110314A (ko) * 2018-03-20 2019-09-30 주식회사 만도 오토사(autosar) 표준에 기반한 인수검사 테스트 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101134735B1 (ko) * 2010-11-03 2012-04-13 재단법인대구경북과학기술원 소프트웨어 컴포넌트 설계정보를 이용한 소프트웨어 테스트 방법 및 시스템
US20140019942A1 (en) * 2012-07-10 2014-01-16 Dspace Digital Signal Processing And Control Engineering Gmbh Method and device for creating and testing a control unit program
KR20180014978A (ko) * 2016-08-02 2018-02-12 (주)씽크포비엘 전장용 소프트웨어 안전성 분석 방법 및 장치
KR20180078697A (ko) * 2016-12-30 2018-07-10 경북대학교 산학협력단 차량용 소프트웨어 테스트 방법
KR20190110314A (ko) * 2018-03-20 2019-09-30 주식회사 만도 오토사(autosar) 표준에 기반한 인수검사 테스트 방법

Also Published As

Publication number Publication date
KR20210065301A (ko) 2021-06-04

Similar Documents

Publication Publication Date Title
WO2021107183A1 (ko) Autosar 기반의 소프트웨어 설계 방법 및 이를 수행하기 위한 장치
WO2014088144A1 (ko) 단위 테스트 케이스 재사용 기반의 함수 테스트 장치 및 그 함수 테스트 방법
WO2019117593A1 (ko) 컨테이너 기반의 자원 할당을 지원하는 클라우드 컴퓨팅 장치 및 방법
EP1119806B1 (en) Configuring system units
US7185335B2 (en) Programmatic application installation diagnosis and cleaning
WO2009110111A1 (ja) サーバ装置及びサーバ装置の異常検知方法及びサーバ装置の異常検知プログラム
US6571360B1 (en) Cage for dynamic attach testing of I/O boards
WO2016111525A1 (ko) 소스코드 이관제어 방법 및 이를 위한 컴퓨터 프로그램, 그 기록매체
WO2012033237A1 (ko) 시스템 테스트 방법
JPH0416813B2 (ko)
WO2019164205A1 (ko) 전자 장치 및 그의 동작 방법
JPH11161625A (ja) コンピュータ・システム
WO2018016671A2 (ko) 보안 취약점 점검을 위한 위험성 코드 검출 시스템 및 그 방법
WO2022124720A1 (ko) 운영체제 커널 메모리의 실시간 오류 검출 방법
WO2013168947A1 (ko) 모니터링 자원의 사용량 표현 방법, 컴퓨팅 장치 및 그 방법을 실행시키기 위한 프로그램을 기록한 기록 매체
WO2020071639A1 (ko) 프로그램 개발 시스템 및 이를 이용한 개발 방법
GB2342471A (en) Configuring system units
CN114064435A (zh) 数据库测试方法、装置、介质与电子设备
US11200154B2 (en) Function modification for software application testing
EP3765965B1 (en) Static software analysis tool approach to determining breachable common weakness enumerations violations
WO2017188620A1 (ko) 주 메모리의 에러 셀 회피를 위한 가상 메모리 관리 장치 및 그 방법
WO2023127997A1 (ko) 차량용 플랫폼을 위한 arinc 기반 운영체제 헬스 모니터링 설정 코드 자동 생성 장치 및 방법
US11169909B2 (en) Flexible test program generation by altering previously used resources
WO2024005246A1 (ko) 코드 검증 정보를 제공하는 전자 장치 및 그 방법
WO2017030337A1 (ko) 사물 인터넷에서의 연관된 트랜잭션 처리 방법, 이를 위한 사물 인터넷 통신 노드, 및 이들을 이용한 사물 인터넷 망

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19954070

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19954070

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 19954070

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 13.12.2022)

122 Ep: pct application non-entry in european phase

Ref document number: 19954070

Country of ref document: EP

Kind code of ref document: A1