KR102158687B1 - Method and apparatus for designing VFB of AUTOSAR using a FBF (Function Block Feature) - Google Patents

Abstract

A method for designing a Virtual Function Bus (VFB) of AUTOSAR (AUTomotive Open System ARchitecture), the method comprising: identifying functional requirements for functions related to operation of a vehicle; Generating a system model consisting of a sensor category, a controller category, and an actuator category based on the functional requirements and hardware of the vehicle; Determining at least one function block feature (FBF) included in each category included in the system model based on the function requirement and the system model; And designing a VFB of AUTOSAR based on the determined FBF for each category included in the system model.

Description

A method and apparatus for designing VFB of AUTOSAR using a FBF (Function Block Feature) {Method and apparatus for designing VFB of AUTOSAR using a FBF (Function Block Feature)}

Various embodiments of the present disclosure relate to a method and apparatus for designing a Virtual Function Bus (VFB) of AUTOSAR (AUTomotive Open System ARchitecture).

Currently, the complexity of functions in automobiles increases, and dozens of ECUs instead of one ECU (Electronic Control Unit) perform complex functions through mutual communication. As the system complexity increases due to the intercommunication of multiple ECUs, the issue of interoperability and reusability of ECU software began to be discussed, and an open automotive software architecture standard called AUTOSAR (AUTomotive Open System Architecture) was developed.

AUTOSAR is an open standard system architecture that can be used by automakers around the world. AUTOSAR improves the portability and reusability of software by dividing the software structure into a hierarchical structure and standardizing the interface.

In AUTOSAR, VFB (Virtual Functional Bus) serves to connect components so that the interaction between components is smooth by abstracting the connection between AUTOSAR software components.

However, in AUTOSAR, the VFB design method and elements are described, and the internal behavior design method and elements are described, but the description of how to design the VFB according to the functional requirements is not specified. Therefore, when designing a VFB, the completeness of the design depends on the designer's knowledge and experience. In addition, there is a problem in that a separate dedicated development tool must be used to manage traceability because there is no clear design basis for the design process until the VFB is designed based on the functional requirements.

Therefore, a method for designing AUTOSAR's VFB according to a clear design basis and improving traceability is required.

Various embodiments of the present disclosure determine a system model and a function block feature (FBF, hereinafter referred to as FBF) based on functional requirements and vehicle hardware, and a method of designing a VFB of AUTOSAR using the determined FBF, and It aims to provide a device.

A method of designing a VFB of AUTOSAR according to an embodiment includes the steps of identifying a functional requirement for a function related to an operation of a vehicle; Generating a system model consisting of a sensor category, a controller category, and an actuator category based on the functional requirements and hardware of the vehicle; Determining at least one function block feature (FBF) included in each category included in the system model based on the function requirement and the system model; And designing a VFB of AUTOSAR based on the determined FBF for each category included in the system model.

According to an embodiment, the determining of at least one FBF included in each category included in the system model includes at least one of an object having an output element or a sensor of the vehicle among software modules inside the controller of the vehicle. Classify as a source entity, classify at least one of an entity having an input element or an actuator of the vehicle among software modules inside the controller as a result entity, and a connection relationship between the source entity and the result entity based on the function requirement And determining as an action, and determining mapping of the source entity, the result entity, and the action as the FBF.

According to an embodiment, determining at least one FBF included in each category included in the system model includes generating an FBF worksheet by mapping the at least one FBF for each category. Including, and designing the VFB of the AUTOSAR may include determining a sensor component, an application component, and an actuator component in the VFB based on the FBF worksheet, and determining a connection relationship between the components. .

According to an embodiment, designing the VFB of the AUTOSAR may further include determining an interface used for connection of the components based on the sensor-actuator pattern of the AUTOSAR.

An apparatus for designing a VFB of AUTOSAR according to an embodiment includes: a function requirement identification unit for identifying a function requirement for a function related to an operation of a vehicle; A system model generation unit that generates a system model composed of a sensor category, a controller category, and an actuator category based on the functional requirement and the hardware of the vehicle; An FBF analysis unit that determines at least one function block feature (FBF) included in each category included in the system model based on the function requirement and the system model; And a design unit for designing a VFB of AUTOSAR based on the determined FBF for each category included in the system model.

According to the VFB design method of AUTOSR according to various embodiments of the present disclosure, a system model and FBF are determined based on functional requirements, and a VFB is designed according to the determined FBF, thereby providing a consistent and formal VFB design basis. There are, and the inconsistency between functional requirements and design can be resolved.

In addition, by setting a feature ID for each feature when determining the FBF, it is possible to easily track the functional requirements for the VFB component based on the standardized design procedure and the feature identifier.

1 is a diagram showing a FDD (Feature Driven Development) process.
2 is a diagram showing a sensor-actuator pattern of AUTOSAR.
3 is a flowchart illustrating a method of designing a VFB of AUTOSAR according to an embodiment.
4 is a flowchart illustrating a method of determining a Function Block Feature (FBF) based on a function requirement according to an embodiment.
5 is a diagram illustrating a system model of a VFB design method according to an embodiment.
6 is a diagram showing a correlation between a function requirement and a sensor-actuator pattern of AUTOSAR and a measured value level.
7 is a diagram showing the classification of AUTOSAR software components in the sensor-actuator pattern of AUTOSAR.
8 is a diagram for describing an example of a VFB designed according to a VFB design method according to an embodiment.
9 is a block diagram showing the configuration of a VFB design apparatus according to an embodiment.

Terms used in the embodiments of the present disclosure have selected general terms that are currently widely used as possible while considering functions in the disclosed embodiments, but this is according to the intention or precedent of a technician working in the field, the emergence of new technologies, etc. It can be different. In addition, in certain cases, there are terms arbitrarily selected by the applicant, and in this case, the meaning will be described in detail in the corresponding part. Therefore, the terms used in the disclosed embodiments should be defined based on the meaning of the term and the contents throughout the disclosed embodiments, rather than a simple name of the term.

Since the embodiments of the present disclosure may be modified in various ways and may have various forms, some embodiments will be illustrated in the drawings and described in detail. However, this is not intended to limit the embodiments of the present disclosure to a specific form of disclosure, and it should be understood that all changes, equivalents, and substitutes included in the spirit and scope of the embodiments of the present disclosure are included. The terms used in the present specification are only used to describe the embodiments, and are not intended to limit the disclosed embodiments.

Terms used in the embodiments of the present disclosure have the same meaning as commonly understood by one of ordinary skill in the art to which the disclosed embodiments belong, unless otherwise defined. Terms as defined in a commonly used dictionary should be interpreted as having a meaning consistent with the meaning in the context of the related technology, and in an ideal or excessively formal meaning unless explicitly defined in the disclosed embodiments. Should not be interpreted.

Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings.

1 is a diagram showing a FDD (Feature Driven Development) process.

In FIG. 1, in order to describe a VFB design method of AUTOSAR according to various embodiments of the present disclosure, first, a feature, a function block feature (FBF), and a feature driven development (FDD) process are described. Explain about it.

Features are derived from Feature Engineering and mean software features such as Performance, Portability, Functionality, and/or software features specified or implied by requirements documentation. Features were mainly used in domain analysis techniques during the software-related development process.

FDD (Feature Driven Development) is an agile S/W development process that develops S/W in an iterative and incremental way. Referring to FIG. 1, in the FDD process, the requirements are separated into feature units through five steps to develop. First, we define the domain model. Second, a feature list defined as <Action>, <Result>, and <Object> is derived from one functional element among at least one functional element included in the domain model. Third, a functional element development plan using features is established, and fourth, a detailed sequence diagram for the function of the feature is defined, and the functional elements are designed using features. Finally, the functional design is completed by building through the specification of the designed feature, and this is repeatedly performed for other functional elements included in the domain model.

Function Block is one of the languages introduced in IEC 61131-3, a control system standard, and used for control configuration in PLC. A function block is a function having an input variable and an output variable, and the above-described function is called a basic block set. The basic set of blocks consists of input variables, output variables, and functions to perform. Input and output variables can be connected between blocks by connecting lines. The connecting line can only transmit data in one direction. The connection line supports a total of three connections, namely, an input variable and an input of a block, an output and an output variable of a block, and an output of a block and an input of another block.

In a VFB design method according to various embodiments of the present disclosure, a VFB is designed using a function block feature (FBF) in which a function block is configured as a feature. In addition, in the method of determining the FBF, a part of the process of FDD that is developed by deriving the feature list defined as <Action>, <Result>, and <Object> from the functional element was modified and reflected. Details of the VFB design method using FBF will be described in FIG. 3.

First, hereinafter, the software structure of AUTOSAR, which is the basis of VFB design, will be described with reference to FIG. 2.

2 is a diagram showing a sensor-actuator pattern of AUTOSAR.

The software structure of AUTOSAR is an MCAL that directly accesses hardware such as a sensor or actuator, and an ECU abstraction, and an application software layer that does not have hardware dependencies by being connected to hardware through sensors and actuators. It is divided into. And the elements that compose each layer are encapsulated as software components.

AUTOSAR follows the sensor-actuator pattern shown in FIG. 2 among the design patterns of software for the aforementioned software structure. The sensor-actuator pattern is also referred to as device abstraction.

The sensor-actuator pattern represents the connected motion of the hardware sensors and actuators connected to the ECU in relation to the overall AUTOSAR architecture. In addition, the sensor-actuator pattern represents a structure that ensures the independence of the application software with the sensors and actuators connected to a specific ECU, and enables the design of reusable software components between different types of sensors and actuators.

Hereinafter, a specific method of designing a VFB using FBF according to various embodiments of the present disclosure will be described.

3 is a flowchart illustrating a method of designing a VFB of AUTOSAR according to an embodiment.

In step 310, functional requirements for functions related to the operation of the vehicle are identified.

In order to design AUTOSAR's VFB as FBF, first of all, it is necessary to identify the function requirements and understand the functions that the system must perform.

The functional requirements for functions related to the operation of the vehicle refer to the operation of the vehicle, such as lighting of a vehicle headlight, lighting of a vehicle instrument panel, and operation of a vehicle brake, and detailed procedures for performing the operation. Table 1 below is an example of vehicle function requirements.

[Table 1]

For example,'vehicle headlights on' and'vehicle headlights are turned on when the driver activates the vehicle's headlights on switch' can be identified as functional requirements.

In addition, in order to consistently design multiple functional requirements and improve traceability, a function requirement identifier (Function Requirement ID) is set for each functional requirement as described in [Table 1]. I can. For example, the identifier of a function requirement related to lighting of a vehicle headlight may be set as FR-001 (Function Requirement-001).

In step 320, a system model consisting of a sensor category, a controller category, and an actuator category is generated based on the functional requirements and the hardware of the vehicle.

By creating a system model composed of the sensor, controller, and actuator categories, the design of the VFB can be easily proceeded by clearly grasping the system components, functions of the system, and the flow of functions.

Referring to FIG. 5, a system model for the functional requirements described in [Table 1] of step 310 is shown. The sensor category 510 of the system model shown in FIG. 5 includes vehicle headlight switches and vehicle brake pedals, the controller category 520 includes an ECU, and the actuator category 530 includes vehicle headlights as vehicle hardware. , Vehicle instrument panel LEDs, and vehicle brakes.

Referring back to FIG. 3, in step 330, at least one FBF included in each category included in the system model is determined based on the function requirement and the system model.

The FBF model consists of a source object, a result object, and an action. A source object is an object that abstracts the storage and/or device of an object that affects other objects. The resulting object is an object abstracting the storage and/or device of an object affected by another object.

For example, since a hardware sensor transmits information about the surrounding environment to software as data, the hardware sensor is a source entity that affects software, and the software affected by the hardware sensor is a result entity. Likewise, if one software affects another software, the affected software is the source entity and the affected software is the result entity.

Actions represent how the source entity affects the resulting entity. At the measured value level, the action can be composed of a total of 4 types: Read, Transfer, Process, and Write. The four items of action are shown in Table 2 below.

[Table 2]

On the other hand, the measured value level is a concept of viewing sensors, controllers and actuators through the system model from the user's point of view.

When the sensor is operated, predetermined data is stored in a storage space of the sensor as a human-recognizable value, and the stored value is transmitted to the controller (ECU) through a predetermined interface. The controller processes the data received from the sensor to create a command, stores the command as a value, and transmits it to the actuator through a predetermined interface. The transmitted command is stored as a value in the storage space of the actuator, and the actuator operates by referring to the stored value.

As described above, the concept viewed from the user's point of view of the process of operating the actuator by stepwise processing of the measured value of the sensor is referred to as the measured value level.

In order to determine the FBF for each category at the measured value level, first, in the population consisting of the vehicle's hardware sensor object, the controller's internal software module object, and the hardware actuator object, according to the functional requirements, the sensor category of the system model, the controller category, and And identify entities that should be included in each of the actuator categories.

Referring to FIG. 6, the correlation between the functional requirements and the sensor-actuator pattern of AUTOSAR is shown. As shown in FIG. 6, objects 610 that should be included in the sensor category 510 of the system model, objects 620 that should be included in the controller category 520, and the actuator category 530 should be included. The entities 630 may be identified according to functional requirements.

Referring back to FIG. 3, in step 330, entities that are affected by each other are identified based on functional requirements for entities included in each category of the system model.

Then, based on the functional requirements, the actions between the entities affecting and affecting each other are identified.

Finally, for each category of the system model, one FBF is mapped by mapping the first entity that affects the second entity, the second entity that is affected by the first entity, and the action between the first entity and the second entity. To decide. As described above, for all actions and entities included in each category, actions and entities associated with each other are determined as one FBF, and an FBF list is generated.

4, a flow chart of a method of determining an FBF based on a functional requirement according to an embodiment is shown. Steps 410 to 440 of FIG. 4 may correspond to detailed steps of step 330 of FIG. 3.

In step 410 of FIG. 4, at least one of an object having an output element or a vehicle sensor among software modules inside the vehicle controller is classified as a source object.

Since the source entity is an entity that affects other entities, it is possible to classify entities that have output elements mainly among hardware sensors or software modules inside the controller as source entities.

In step 420, at least one of an object having an input element or an actuator of a vehicle among software modules inside the controller is classified as a result object.

Since the result entity is an entity that is affected by other entities, it is possible to classify entities that have an input element among hardware actuators or software modules inside the controller as result entities.

In step 430, a connection relationship between the source entity and the result entity is determined as an action based on the function requirement.

That is, among the determined source entities and result entities, the relationship between the source entity and the result entity is analyzed based on the functional requirements and the system model, and then the source entity and the result entity affected by each other are mapped. Then, according to the relationship according to the functional requirements between the mapped source entity and the result entity, an action between the two entities is determined from among the four action types.

In step 440, the mapping of the source entity, the result entity, and the action is determined as FBF.

In other words, one source object and one result object, which are affected by each other, and an action between the two objects are mapped to one FBF.

Referring back to FIG. 3, in step 330, for example, an action, a source entity, and a result entity mapped to one FBF may be represented as shown in Table 3 below.

[Table 3]

In addition, it is possible to generate an FBF Worksheet by synthesizing FBFs included in each category of a system model of one functional requirement. For example, the measured value level FBF worksheet for the'vehicle headlight lighting' function requirement in [Table 1] can be configured as shown in [Table 4].

[Table 4]

As described in [Table 4], a feature ID (Feature ID) can be set for each FBF, and for the designed VFB component, it is possible to easily track the categories related to the VFB component, affected entities and actions, etc. have.

In addition, the system model category was classified into sensor category, controller category, and actuator category, but as shown in [Table 4], FBF can be classified into categories of sensing, control, and actuation. I can. The reason FBFs are classified into sensing, control, and operation categories is that the source entity or result entity mapped to each of the FBFs may be hardware sensors or hardware actuators as well as software components.

In [Table 4], Light_Switch is an abstraction object of the vehicle headlight switch, and SW_Light_Ctl is an abstraction object of software that processes data inside the ECU. Light_Act is an abstract object of the vehicle headlight, and LightSwitch_Val and LightAct_Val are objects abstracting data transmitted between the vehicle headlight switch and the ECU, and the ECU and the vehicle headlight in the system model shown in FIG. 5. The transmitted data abstraction object is transmitted through an interface connecting two different objects.

In addition, for designing VFBs for multiple functional requirements, an FBF worksheet for each functional requirement can be generated. For example, the measured value level FBF worksheet for the'Vehicle instrument panel LED lighting' function requirement in [Table 1] can be configured as shown in [Table 5].

[Table 5]

In addition, the measured value level FBF worksheet for the function requirements of'vehicle brake operation' in [Table 1] can be composed as shown in [Table 6].

[Table 6]

In step 340, the VFB of AUTOSAR is designed based on the FBF determined for each category included in the system model.

Through the FBFs included in each of the sensor, controller, and actuator categories of the system model for the functional requirements, determined through steps 310 to 330, the connection relationships for each of the entities included in the system model are clearly identified. Therefore, the classification of AUTOSAR software components in the sensor-actuator pattern of AUTOSAR, and the FBF for each category determined in step 330, are used to design a VFB by establishing a connection relationship between the VFB components and the VFB components of AUTOSAR.

Referring to Fig. 7, the classification of AUTOSAR software components in the sensor-actuator pattern of AUTOSAR is shown. VFB design includes designing an application component, a sensor component, and a connection relationship thereof. MCAL is provided by the supplier of the board used and is not included in the VFB design stage.

In addition, since ECU Abstraction components are closely related to hardware, in order to allow each component of AUTOSAR software to access hardware, at least one ECU Abstraction component must be included in the VFB design.

In the present disclosure, for convenience of description, designing a VFB including one ECU Abstraction component will be described as an example. However, it goes without saying that a plurality of ECU abstraction components may be included when designing a VFB. According to an embodiment, an interface used for connection of components may be determined based on a sensor-actuator pattern of AUTOSAR. For example, for the AUTOSAR interface, it can be decided to use the Client-Server Interface for the connection relationship between the ECU Abstraction and the sensor/actuator component, and the Sender-Receiver Interface for the connection relationship between the sensor/actuator and the application component. .

Referring back to FIG. 3, in step 340, a sensor component, an application component, and an actuator component are determined in the VFB, based on at least one FBF worksheet generated by synthesizing FBFs for each function requirement and category. VFBs can also be designed by determining the connection relationships between components.

Referring to FIG. 8, an example of a VFB designed according to the VFB design method described with reference to FIG. 3 is shown. 8 shows the creation of TopLevelComposition for the design up to the VFB stage.

Referring to FIG. 8, each sensor component receives the vehicle headlight switch status and vehicle brake pedal status using a Client-Server Interface from one ECU Abstraction (CPT_ECU_ABS), and each sensor component receives the received data as an application component. It is transmitted to Brake_Ctl and Light_Ctl by using Sender-Receiver Interface.

Since Brake_Ctl needs to activate the vehicle brake by generating a vehicle brake operation command, it transmits the command to the actuator component Brake_Act using the Sender-Receiver Interface. Likewise, Light_Ctl needs to activate each actuator by generating operation commands for vehicle headlights and vehicle instrument panel LEDs, so it transmits commands to the actuator components Car_Light_Act and InstPanel_Act using the Sender-Receiver Interface.

Since the three actuator components, Brake_Act, Car_Light_Act, and InstPanel_Act, need to transmit data to the ECU Abstraction so that the actual hardware actuator can operate, the command data is transmitted to the ECU Abstraction using the Client-Server Interface.

According to the AUTOSAR VFB design method described with reference to FIG. 3, by determining the system model and FBF based on the functional requirements, and designing the VFB according to the determined FBF, it is possible to provide a consistent and formal VFB design basis, Inconsistency between functional requirements and design can be resolved. For example, when designing an FBF, the result entity of one FBF becomes the source entity of the next step FBF, and each FBF is designed to be connected, so that each step can be designed based on the previous step even in VFB design.

In addition, by setting the identifier for the functional requirements and the identifier (feature ID) for each feature when determining the FBF, it is possible to facilitate tracking of the functional requirements for the VFB component based on the formal design procedure and identifier. . For example, it can be seen that the Car_Light_Act Component of FIG. 8 is related to FBF-004 and FBF-005 in [Table 4] of the FBF, and thus, is related to the functional requirement FR-001.

9 is a block diagram showing the configuration of a VFB design apparatus according to an embodiment.

Referring to FIG. 9, the VFB design apparatus 900 includes a processor 910 and may additionally include a memory 920. The processor 910 includes a function requirement identification unit 912, a system model generation unit 914, an FBF analysis unit 916, and a VFB design unit 918.

In the VFB design apparatus 900 shown in FIG. 9, only the components related to this embodiment are shown. Accordingly, it can be understood by those of ordinary skill in the art related to the present embodiment that other general-purpose components other than the components shown in FIG. 9 may be further included in the VFB design apparatus 900.

The processor 910 is hardware that controls the overall function and operation of the VFB design apparatus 900, and executes various instructions, applications, etc. stored in the memory 920 to perform a VFB design method according to various embodiments of the present disclosure. Can be done. The processor 910 may be implemented with a central processing unit (CPU), a graphics processing unit (GPU), an application processor (AP), or the like provided in the VFB design apparatus 900, but is not limited thereto.

The memory 920 is hardware that stores various types of data processed in the VFB design apparatus 900, and may store data processed for VFB design and data to be processed by the VFB design apparatus 900. The memory 920 includes a random access memory (RAM) such as dynamic random access memory (DRAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and CD- ROM, Blu-ray or other optical disk storage, hard disk drive (HDD), solid state drive (SSD), or flash memory.

The function requirement identification unit 912 identifies function requirements for functions related to the operation of the vehicle.

The system model generation unit 914 generates a system model composed of a sensor category, a controller category, and an actuator category based on the functional requirements and the hardware of the vehicle.

The FBF analysis unit 916 determines at least one FBF included in each category included in the system model based on the functional requirement and the system model.

The VFB design unit 918 designs the VFB of AUTOSAR based on the FBF determined for each category included in the system model.

According to some embodiments, the processor 910 classifies an object having an output element among software modules inside a vehicle controller or at least one of a vehicle sensor as a source object, and classifies an object having an input element among software modules inside the controller or By classifying at least one of the actuators of the vehicle as a result entity, determining a connection relationship between the source entity and the result entity as an action based on the functional requirements, and determining the mapping of the source entity, the result entity, and the action as FBF, the system At least one FBF included in each category included in the model may be determined.

According to some embodiments, the processor 910 generates an FBF worksheet by mapping at least one FBF for each category, and determines a sensor component, an application component, and an actuator component in the VFB based on the FBF worksheet. And, you can design AUTOSAR's VFB by determining the connection relationship between components.

According to some embodiments, the processor 910 may design the VFB of AUTOSAR by determining an interface used for connecting components based on the sensor-actuator pattern of AUTOSAR.

The method of operating the apparatus according to the disclosed embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer-readable medium. The above-described computer-readable medium may include program instructions, data files, data structures, and the like alone or in combination. The program instructions recorded in the above-described medium may be specially designed and configured for the present invention, or may be known and usable to those skilled in computer software. The above-described computer-readable medium may be included in a computer program product.

Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks. -A hardware device specially configured to store and execute program instructions such as magneto-optical media, and ROM, RAM, flash memory, and the like. Examples of the program instructions include not only machine language codes such as those produced by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like.

The disclosed embodiment can be represented by functional block configurations and various processing steps. These functional blocks may be implemented with various numbers of hardware or/and software configurations that perform specific functions. For example, the disclosed embodiment is an integrated circuit configuration such as memory, processing, logic, look-up table, etc., capable of executing various functions by controlling one or more microprocessors or other control devices. Can be hired. Similar to how the components of the disclosed embodiment can be implemented with software programming or software elements, the disclosed embodiment includes various algorithms implemented with a combination of data structures, processes, routines or other programming components, including C, C++. , Java, assembler, or the like may be implemented in a programming or scripting language. Functional aspects can be implemented with an algorithm running on one or more processors. In addition, the disclosed embodiments may employ conventional techniques for electronic environment setting, signal processing, and/or data processing.

On the other hand, those of ordinary skill in the technical field related to the disclosed embodiment will appreciate that it may be implemented in a modified form within a range not departing from the essential characteristics of the above-described description. Therefore, the disclosed methods should be considered from an explanatory point of view rather than a limiting point of view. The scope of the present invention is shown in the claims rather than the above description, and all differences within the scope equivalent thereto should be construed as being included in the present invention.

Claims (5)

In a method for designing a VFB of AUTOSAR, performed by a device that designs a Virtual Function Bus (VFB) of AUTOSAR (AUTomotive Open System ARchitecture),
Controlling a function requirement identification unit included in the device to identify a function requirement for a function related to the operation of the vehicle;
Generating a system model composed of a sensor category, a controller category, and an actuator category based on the function requirement and hardware of the vehicle by controlling a functional system model generator included in the device;
At least one FBF included in each category included in the system model based on the function requirement and the system model by controlling a function block feature (FBF) analysis unit included in the device Determining; And
Controlling a design unit included in the device, and designing a VFB of AUTOSAR based on the determined FBF for each category included in the system model,
Determining at least one FBF included in each category included in the system model,
Classifying at least one of an object having an output element or a sensor of the vehicle among software modules inside the vehicle controller as a source object,
Classifying at least one of an object having an input element or an actuator of the vehicle among software modules inside the controller as a result object,
Determining a connection relationship between the source entity and the result entity as an action based on the functional requirement,
Determining a mapping of the source entity, the result entity, and the action to the FBF. delete The method of claim 1,
Determining at least one FBF included in each category included in the system model,
Including the step of generating an FBF worksheet (Worksheet) by mapping the at least one FBF for each category,
The step of designing the VFB of AUTOSAR,
Determining a sensor component, an application component, and an actuator component in the VFB based on the FBF worksheet, and determining a connection relationship between the components. The method of claim 3,
The step of designing the VFB of AUTOSAR,
The method further comprising determining, based on the AUTOSAR's sensor-actuator pattern, an interface used to connect the components. In the device for designing a VFB (Virtual Function Bus) of AUTOSAR (AUTomotive Open System ARchitecture),
A function requirement identification unit for identifying a function requirement for a function related to the operation of the vehicle;
A system model generation unit that generates a system model composed of a sensor category, a controller category, and an actuator category based on the functional requirement and the hardware of the vehicle;
An FBF analysis unit that determines at least one function block feature (FBF) included in each category included in the system model based on the function requirement and the system model; And
Including a design unit for designing the VFB of AUTOSAR based on the determined FBF for each category included in the system model,
The FBF analysis unit,
Classifying at least one of an object having an output element or a sensor of the vehicle among software modules inside the vehicle controller as a source object,
Classifying at least one of an object having an input element or an actuator of the vehicle among software modules inside the controller as a result object,
Determining a connection relationship between the source entity and the result entity as an action based on the functional requirement,
Determining the mapping of the source entity, the result entity, and the action to the FBF.

Images