JP2012063826A - Program generation device, method and program, and remote management system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To easily generate a program executed in built-in equipment that comprises several processors and realizes a prescribed function.SOLUTION: A program generation device comprises: storage means storing in advance communication processing information which implements communication processing between several processors; configuration information generation means generating configuration information defining configuration of a prescribed function in built-in equipment by several nodes; node state information generation means generating node state information defining a state of a node and action information which is a behavior of the node in that state for each of several nodes defined in the configuration information; converting means converting the action information into a program code realizing a process corresponding to the behavior of the node in that node state; and program generation means generating several programs that correspond to each of the several processors based on the configuration information, the programs including the communication processing information stored in the storage means and the converted program code.

Description

  The present invention relates to a program generation apparatus, method, and program, and a remote management system, and more particularly to a program generation apparatus, method, and program for generating a program that includes a plurality of processors and that can be executed by an embedded device that realizes a predetermined function. And a remote management system.

  In recent years, not only a plurality of control system ECUs (Electronic Control Units) but also information system ECUs are mounted on automobiles. Here, the control system ECU refers to an electronic control device for controlling an automobile body such as an engine control system or a body system. In general, several tens to hundreds of control system ECUs are mounted on an automobile. The information system ECU refers to an electronic control device for controlling functions such as multimedia functions such as a car navigation system and an AV (Audio Visual) system. The information system ECU can be controlled more flexibly than the control system ECU by executing a program by an internal processor. Therefore, the information system ECU may control a plurality of control system ECUs by a program.

  For these reasons, the development of automobiles is generally performed by a plurality of development teams and suppliers. In the future, not only the control system ECU but also the information system ECU is expected to have a plurality of configurations. Also, in major manufacturers, the development department and the maintenance department are separated, and development and maintenance are often performed by different engineers.

  Here, there is DMT (Device Management Tree) as a technique for defining a device configuration for managing various functions of an automobile or the like in units of devices. The DMT is tree structure data used for device management. The name of each node can be expressed as a URI (Uniform Resource Identifier). Therefore, the device management server on the network and the device management application in the embedded device can read / write and issue an execution command to any node in the DMT by specifying the URI. It is also possible to dynamically add nodes to the DMT.

  Moreover, there is OMA-DM (Open Mobile Alliance-Device Management) as a DMT-based device management technology. OMA-DM is a standard for a remote device management protocol used in 3G mobile phones and WIMAX (Worldwide Interoperability for Microwave Access). The standardization organization is OMA (Open Mobile Alliance). OMA-DM manages devices in units of MO (Management Object) corresponding to DMT. Standard MOs provided by OMA-DM include FUMO (remote firmware update), SCOMO (remote SW update), Diamon (remote diagnosis), and LAWMO (remote security lock). For example, Patent Document 1 discloses a technique for managing a mobile device.

  In addition, the current status of in-vehicle device diagnosis is as follows. First, regarding the control system ECU, a service engineer performs diagnosis and control by connecting a diagnostic tester to a connector called OBD2. As for the information system ECU, a method of acquiring log information from a storage connected to the information system ECU after being brought into a service center is currently mainstream.

  Recently, in order to manage various functions of automobiles, a remote diagnosis program using a remote device management protocol that supports DMT such as OMA-DM is embedded in the information ECU in advance, or after the product is shipped, Methods such as sending a diagnostic program to the information system ECU are considered. The latter is used when sending a special diagnostic program to a specific vehicle that has been found to have a potential defect after shipment.

  Patent Document 2 discloses a technique relating to a vehicle diagnostic program creation device and a vehicle diagnostic device for creating and correcting a vehicle diagnostic program. Patent Document 3 discloses a technique related to a tool device for creating a program for performing communication and identifying the cause when there is an error.

Special table 2009-504041 gazette JP 2000-131194 A JP 2009-020716A

  Thus, in order to create a remote diagnosis program corresponding to a plurality of information system ECUs, a wide range of specialized knowledge is required, and it is difficult for a service engineer who performs maintenance work to perform alone. there were. This is because the above-described diagnostic program must be created by programming by engineers in the development department familiar with each ECU. Therefore, the threshold is high for the service engineer of the maintenance department or service center to create.

  Here, in order to create a remote diagnosis program corresponding to a plurality of information system ECUs, the following knowledge is required. First, knowledge about the programming language used in each information system ECU, the OS (Operating System) system call, and the design concept unique to the system is required. For example, the first information system ECU requires knowledge of Linux (registered trademark) and C ++, and the second information system ECU requires knowledge of T-kernel and C language. . Furthermore, knowledge of the OMA-DM protocol and the DMT sharing method between each information system ECU, an in-vehicle diagnostic protocol for the control system ECU, and an event acquisition method from another ECU is also required.

  In the techniques according to Patent Documents 1 to 3, in an embedded device including a plurality of control system ECUs and a plurality of information system ECUs, communication processing between the information system ECUs must be individually implemented. The problem cannot be solved.

  The present invention has been made in order to solve such problems, and can be executed on an embedded device without a need for extensive expertise in an embedded device having a plurality of processors and realizing a predetermined function. An object of the present invention is to provide a program generation apparatus, method and program for easily generating a program to be executed, and a remote management system.

  The program generation apparatus according to the first aspect of the present invention includes communication processing information that is a program module in which a plurality of processors are mounted and communication processing between the plurality of processors in an embedded device that realizes a predetermined function. Storage means for storing in advance; configuration information generating means for generating configuration information in which the configuration of the predetermined function in the embedded device is defined by a plurality of nodes; and for each of the plurality of nodes defined in the configuration information, Node state information generating means for generating node state information that defines the state and action information that is the behavior of the node in the state, and the action information defined in the node state information, to the behavior of the node in the state of the node Conversion means for converting into program code for realizing corresponding processing, and the configuration Based on the distribution, a plurality of programs corresponding to each of the plurality of processors, comprising the communication processing information stored in the storage means, and a program generation means for generating including program code the converted.

  According to a second aspect of the present invention, there is provided a program generation method for generating configuration information in which a plurality of processors are mounted and a configuration of a predetermined function in an embedded device that realizes a predetermined function is defined by a plurality of nodes. For each of the plurality of nodes defined in the configuration information, node state information that defines the node state and action information that is the behavior of the node in the state is generated, and from the action information defined in the node state information, Converts into program code that realizes processing corresponding to the behavior of the node in the node state, and implements a plurality of programs corresponding to each of the plurality of processors based on the configuration information in communication processing between the plurality of processors Communication processing information, which is a converted program module, and the converted program code. To generate Te.

  The program generation program according to the third aspect of the present invention is provided with a plurality of processors and accepts definitions by a plurality of nodes of a configuration of the predetermined function in an embedded device that realizes the predetermined function, and the received definition Generating configuration information based on the above, accepting designation of any of a plurality of nodes included in the configuration information, accepting definitions of the state of the node in the designated node and the action information that is the behavior of the node in the state, Program code that generates node state information based on the received state of the node and the action information path, and realizes processing corresponding to the behavior of the node in the state of the node from the action information defined in the node state information Between the plurality of processors previously stored in the storage unit Communication processing information, which is a program module in which communication processing is implemented, is acquired, and a plurality of programs corresponding to each of the plurality of processors is acquired based on the configuration information, and the acquired communication processing information and the converted program code Is a program that causes a computer to execute processing to be generated.

  An embedded device remote management system according to a fourth aspect of the present invention includes a plurality of processors including a processor capable of wireless communication with the outside, and a communication process between the embedded device that realizes a predetermined function and the plurality of processors. Storage means for storing in advance communication processing information, which is a program module in which is installed, configuration information generating means for generating configuration information in which the configuration of the predetermined function in the embedded device is defined by a plurality of nodes, and the configuration information Node state information generating means for generating node state information that defines a node state and action information that is a behavior of the node in the state for each of a plurality of nodes defined in the above, and an action defined in the node state information A program that realizes processing corresponding to the behavior of the node in the state of the node from the information Conversion means for converting into a program code, a plurality of programs corresponding to each of the plurality of processors based on the configuration information, including the communication processing information stored in the storage means and the converted program code A remote management device comprising: a program generating unit for generating; and a remote control unit for controlling the embedded device by wireless communication, wherein the remote control unit stores the generated plurality of programs in the embedded device. The embedded device causes each of the plurality of programs received from the remote management device to be executed by a corresponding processor among the plurality of processors, and the plurality of processors are included in a program executed by each processor. Processing based on the converted program code to be included in the program. Based on the communication processing, communication between processors.

  According to the present invention, a program generation apparatus, method, and method for easily generating a program to be executed on an embedded device without requiring extensive expertise in the embedded device that includes a plurality of processors and realizes a predetermined function A program and a remote management system can be provided.

It is a block diagram which shows the structure of the program generation apparatus concerning Embodiment 1 of this invention. It is a flowchart which shows the flow of a process of the program production | generation method concerning Embodiment 1 of this invention. It is a block diagram which shows the structure of the remote management system concerning Embodiment 2 of this invention. It is a sequence diagram which shows the flow of a process of the remote management method concerning Embodiment 2 of this invention. It is a block diagram which shows the structure of the remote vehicle-mounted diagnostic system concerning Embodiment 3 of this invention. It is a block diagram which shows the hardware constitutions of the program production | generation apparatus concerning Embodiment 3 of this invention. It is a block diagram which shows the structure of the vehicle-mounted built-in apparatus concerning Embodiment 3 of this invention. It is a figure which shows the concept of the vehicle-mounted diagnostic program produced | generated concerning Embodiment 3 of this invention. It is a figure which shows the example of the DMT access management concerning Embodiment 3 of this invention. It is a figure which shows the concept of the GUI development tool concerning Embodiment 3 of this invention. It is a figure which shows the example of the state model figure and action description language concerning Embodiment 3 of this invention. It is a sequence diagram which shows the flow of a process of the vehicle-mounted diagnostic program for information system ECU33 concerning Embodiment 3 of this invention. It is a sequence diagram which shows the flow of a process of the vehicle-mounted diagnostic program for information system ECU32 concerning Embodiment 3 of this invention. It is a figure which shows the example of the state model figure concerning Embodiment 3 of this invention. It is a figure which shows the example of the class diagram at the time of designing by related technology. It is a figure which shows the example of UML modeling at the time of designing by related technology. It is a figure which shows the concept of the device management using DMT concerning Embodiment 3 of this invention. It is a figure which shows the concept of the program creation procedure at the time of using related technology. It is a figure which shows the concept of the program production | generation method concerning Embodiment 3 of this invention.

  Hereinafter, specific embodiments to which the present invention is applied will be described in detail with reference to the drawings. In the drawings, the same elements are denoted by the same reference numerals, and redundant description will be omitted as necessary for the sake of clarity.

<Embodiment 1 of the Invention>
FIG. 1 is a block diagram showing a configuration of a program generation device 1 according to the first exemplary embodiment of the present invention. The program generation device 1 is a computer system that generates a program that is mounted on a built-in device (not shown) that has a plurality of processors and implements a predetermined function. In particular, the program generation device 1 generates a plurality of programs corresponding to each of the plurality of processors. Here, each of the plurality of generated programs is a machine language program that can be executed by a corresponding processor or a source program that can be compiled into the machine language program. In addition, the plurality of generated programs are programs for realizing a predetermined function of the embedded device, or a program for realizing an auxiliary function for examining or diagnosing the function. The plurality of generated programs are executed on each corresponding processor by being transferred from the program generation apparatus 1 to the embedded device using existing wired communication or wireless communication means. In addition, the generated programs can communicate with each other when executed by each processor.

  The program generation device 1 includes a storage unit 11, a configuration information generation unit 12, a node state information generation unit 13, a conversion unit 14, and a program generation unit 15. The storage unit 11 is a storage device that stores in advance communication processing information 111 that is a program module in which communication processing between a plurality of processors is implemented. The configuration information generation unit 12 generates configuration information in which a configuration of a predetermined function in the embedded device is defined by a plurality of nodes. The configuration information includes not only physical components of embedded devices but also abstract components at the function level. For example, the function name, the part name, the attribute, the parameter value, the measurement value, and the like are expressed as nodes, and the information defines the relationship between the nodes. The node state information generation unit 13 generates, for each of a plurality of nodes defined in the configuration information, node state information that defines the node state and action information that is the behavior of the node in the state. The conversion unit 14 converts the action information defined in the node state information into a program code that realizes processing corresponding to the behavior of the node in the state of the node. The program generation unit 15 generates a plurality of programs corresponding to each of the plurality of processors, including the communication processing information 111 stored in the storage unit 11 and the converted program code, based on the configuration information. Note that the configuration information generation unit 12, the node state information generation unit 13, the conversion unit 14, and the program generation unit 15 execute a program generation program that implements these functions by a control unit such as a CPU (Central Processing Unit). It can be realized by executing. In the first embodiment of the present invention, it is assumed that the association between the defined node and the processor is defined in advance.

  FIG. 2 is a flowchart showing a flow of processing of the program generation method according to the first exemplary embodiment of the present invention. First, the configuration information generation unit 12 generates configuration information (S11). At this time, the configuration information generation unit 12 may receive information related to the function configuration and designation of a plurality of nodes from the outside. Next, the node state information generation unit 13 refers to the configuration information and generates a plurality of node state information corresponding to each of the plurality of nodes (S12). At this time, the node state information generation unit 13 may accept the node state and action information from the outside.

  Then, the conversion unit 14 converts the action information defined in the node state information into a program code that realizes processing corresponding to the behavior of the node in the state of the node (S13). The program code to be converted may be at least source code, not machine code. However, the conversion unit 14 converts the action information into a program code corresponding to a processor associated with the node in advance. The conversion unit 14 converts the action information defined for each of the plurality of node state information into different program codes.

  Thereafter, the program generation unit 15 generates a plurality of programs corresponding to the plurality of processors based on the configuration information (S14). That is, the program generation device 1 generates a plurality of programs from one piece of configuration information for the embedded device. At that time, the program generation unit 15 reads the communication processing information 111 from the storage unit 11 and includes it in each program. That is, the generated program is implemented with communication processing with other processors. Further, the program generation unit 15 includes the program code converted in step S13 in the program corresponding to the node. That is, by defining the action information, the program code corresponding to the processor is implemented.

  As described above, according to the first embodiment of the present invention, a plurality of programs that can be executed by each of a plurality of processors are generated using information representing a predetermined function of an embedded device such as configuration information and node state information. Can do. On the other hand, a service engineer or the like generally has expertise on a predetermined function, but generally does not have extensive expertise on programming that can be executed by a plurality of processors. Therefore, according to the first embodiment of the present invention, even a service engineer or the like can easily generate a program that includes a plurality of processors and is executed by an embedded device that realizes a predetermined function.

<Embodiment 2 of the Invention>
FIG. 3 is a block diagram showing a configuration of the remote management system 10 according to the second exemplary embodiment of the present invention. In the second embodiment of the present invention, an example realized by using the program generation apparatus 1 according to the first embodiment of the present invention will be described. In addition, the same code | symbol is attached | subjected about the component same as Embodiment 1 of invention, and detailed description is abbreviate | omitted.

  The remote management system 10 includes a remote management device 1a and an embedded device 2. The remote management system 10 is a mechanism for remotely managing various functions of the embedded device 2 using the remote management device 1a. The remote management device 1a further includes a remote control unit 16 in addition to the components of the program generation device 1. The remote control unit 16 controls the embedded device by wireless communication. Specifically, the remote control unit 16 transfers a plurality of programs generated by the program generation unit 15 to the embedded device 2 by wireless communication. In addition, the remote control unit 16 gives various control instructions to each program in the embedded device 2. Thereby, the remote management device 1a remotely manages the embedded device 2.

  The embedded device 2 includes processors 21a, 21b,. The embedded device 2 realizes a predetermined function by using at least a part of the processors 21a, 21b,. The processor 21a has a function of wireless communication with the outside. The processor 21a is capable of wireless communication with at least the remote control unit 16.

  FIG. 4 is a sequence diagram showing a processing flow of the remote management method according to the second exemplary embodiment of the present invention. First, the remote management device 1a generates a plurality of programs for each processor by processing equivalent to steps S11 to S14 in FIG. That is, the remote management device 1a generates a machine language program corresponding to each of the processors 21a, 21b,.

  Next, the remote control unit 16 transmits a plurality of programs to the processor 21a of the embedded device 2 (S15). Then, the processor 21a transmits each of the plurality of programs received from the remote management device 1a to the corresponding processor (S16). That is, the processor 21a transmits a program executable on the processor 21b to the processor 21b and a program executable on the processor 21n to the processor 21n.

  Then, the processors 21a, 21b,..., And 21n execute the received programs (S17). The processors 21a, 21b,..., And 21n perform processing based on a program code included in a program executed by each processor. Here, the program code is converted for each processor based on the action information in step S13. Therefore, each processor can execute processing corresponding to the behavior of the node in the state of the node.

  Further, the processors 21a, 21b,..., And 21n perform communication between the processors based on the communication process included in the program executed by each processor (S18). For example, the processors 21a and 21b generate an event for each node between the processors, and respond to the event.

  Thus, according to the second embodiment of the present invention, the same effects as those of the first embodiment of the present invention can be achieved.

<Third Embodiment of the Invention>
In order to create a remote diagnosis program corresponding to a plurality of information system ECUs, a method of automatically generating a diagnosis program from a remote diagnosis specification using MDA (registered trademark) (Model Drive Architecture) can be considered. This is because by introducing MDA, it is possible to lower the threshold of specialized knowledge such as program design and coding technology.

  Here, MDA is a software development technique that provides guidelines for structural specifications expressed as models. When MDA is used, a machine language program can be automatically generated from a model described using a GUI development tool. Development tools using MDA include, for example, BridgePoint and Rhapsody, and are used for embedded software development. In addition, MDA has a method called Executable UML (Unified Modeling Language) that supports an action description language that partially incorporates the syntax of SQL.

  FIG. 18 is a diagram showing a concept of a program creation procedure when MDA is used. First, as an operation corresponding to object-oriented analysis (hereinafter referred to as OOA), UML modeling based on diagnostic specifications is performed (S91). Next, as an operation corresponding to object-oriented design (hereinafter referred to as OOD), UML modeling is performed for functions required for each information system ECU (S92 and S93). Thereafter, source codes SC1 and SC2 are generated from each model by a model compiler corresponding to each information system ECU (S94 and S95).

  However, simply using MDA to create a remote diagnosis program corresponding to a plurality of information system ECUs has the following problems, and it is difficult for a service engineer to do it alone. The problem does not go away.

  (1) It is necessary to generate as many models described in UML as the number of related information system ECUs and compile them with each model compiler. In other words, after step S91 (equivalent to OOA), it is necessary to recreate the model in consideration of the functions assigned to the class library and each information system ECU in a phase equivalent to OOD. In addition, it is necessary to consider separately the cooperation method between models divided for each information system ECU and the communication method with the management center (for example, the remote management device 1a in FIG. 3).

  (2) Object life cycle management (object and event creation, deletion, etc.) must be described by the model creator. This is a contradiction that occurs when an object-oriented design method such as MDA is forcibly brought into device management.

  (3) Communication processing between information system ECUs cannot be automatically generated, and conventional handwritten processing must be implemented.

  (4) Furthermore, when considering cooperation between information system ECUs, the action description at the time of model creation becomes complicated, and eventually the advantage of introducing MDA is lost. In other words, it is necessary to define the allocation of ECUs that communicate wirelessly with the management center. Further, it is necessary to consider a mechanism for allocating to other information system ECUs based on events received from the management center and a mechanism for feeding back actions from other information system ECUs to the management center.

  Therefore, in the third embodiment of the present invention, the concept of a program generation method as shown in FIG. 19 will be described. In FIG. 19, first, modeling based on DMT related to an embedded device to be designed is performed as work equivalent to calling OOA (S41). Therefore, the service engineer can generate a program if the DMT configuration and the allocation of the control system ECU, each sensor, and the information system ECU are known.

  Next, based on the node configuration of the DMT and the behavior of each node, source codes SC1 and SC2 are generated for each of a plurality of ECUs mounted in the embedded device (S42). At this time, the model is automatically divided based on the assignment between the node and the information system ECU. Thereafter, it is built separately by a model compiler corresponding to each information system ECU.

  Thus, by compiling the source codes SC1 and SC2, a machine language program to be executed by each ECU in the embedded device is generated. Here, the generated machine language program includes communication processing between the server of the management center and the embedded device, and cooperation processing of a plurality of ECUs mounted in the embedded device. Further, the third embodiment of the present invention includes a method for configuring an automatically generated machine language program, and a GUI development tool and a model compiler corresponding to them. As described above, according to the third embodiment of the present invention, it is not necessary for the service engineer to describe the logic related to the communication between the information ECUs and the communication with the management center.

  The third embodiment of the present invention can also be realized by improving the program generating apparatus 1 according to the first embodiment of the present invention described above. In that case, it has the following configuration. The configuration information generation unit 12 generates configuration information including allocation information in which one of a plurality of processors is allocated to each node, and the program generation unit 15 assigns each node based on the allocation information included in the configuration information. A plurality of post-classification configuration information is generated by classification into any of a plurality of assigned processors, and a plurality of programs are generated from the generated plurality of post-classification configuration information.

  In addition, a plurality of model compilers for generating a program corresponding to each of the plurality of processors is further provided, and the program generation unit 15 specifies a corresponding processor from the classified configuration information, and selects a model compiler corresponding to the specified processor Then, it is desirable to generate a program that can be executed by the identified processor from the post-classification configuration information using the selected model compiler.

  Furthermore, it is desirable that the program generation unit 15 further includes an asynchronous event corresponding to node access when generating a plurality of programs. In addition, the configuration information generation unit 12 desirably uses DMT as the configuration information. Furthermore, the node state information generation unit 13 may associate the node state information with a rule for processing a processing result of an application operating on a plurality of processors. In addition, the node state information generation unit 13 may associate a rule for performing communication with a control device mounted on an embedded device and controlled by a plurality of processors, with the node state information.

  FIG. 5 is a block diagram showing a configuration of the remote in-vehicle diagnosis system 100 according to the third embodiment of the present invention. The remote in-vehicle diagnosis system 100 includes a development PC 101, a management server 102 in the management center, and an in-vehicle embedded device 103. The remote in-vehicle diagnosis system 100 is a mechanism for remotely diagnosing various functions in the in-vehicle embedded device 103. The remote in-vehicle diagnosis system 100 is mainly a part of a remote device management system that targets on-vehicle embedded devices, but Embodiment 3 of the present invention is not limited to this.

  The development PC 101 creates an in-vehicle diagnostic program using a GUI development tool (S51). The in-vehicle diagnosis program is a plurality of machine language programs corresponding to a plurality of processors mounted on the in-vehicle embedded device 103. Specifically, the development PC 101 receives the configuration, state, action information, and the like of the DMT node from the user, and generates one DMT model information in the in-vehicle embedded device 103. In addition to the DMT-based model information, the development PC 101 generates a plurality of script languages with a high degree of abstraction such as a log filtering rule language and an on-board diagnostic language for a control system ECU.

  The development PC 101 generates a source program corresponding to each ECU by using a model compiler corresponding to each ECU based on the generated DMT model information and script language. That is, the development PC 101 generates a plurality of source programs corresponding to a plurality of processors mounted on the in-vehicle embedded device 103 from one DMT. Thereafter, the development PC 101 converts the plurality of generated source programs into a plurality of binary machine language programs. In this way, the development PC 101 creates a plurality of in-vehicle diagnostic programs.

  Then, the development PC 101 uploads a plurality of in-vehicle diagnosis programs to the management server 102 (S52). The management server 102 transmits a plurality of uploaded in-vehicle diagnostic programs to the in-vehicle embedded device 103 via a wireless communication network (not shown) using a remote device management protocol using radio such as OMA-DM. (S53).

  The in-vehicle embedded device 103 executes the received plurality of in-vehicle diagnostic programs on the corresponding processor. Each processor performs an action on the management server 102 and the in-vehicle embedded device 103 itself based on the diagnosis information acquired by executing the in-vehicle diagnosis program (S54). Further, the management server 102 performs remote diagnosis of the in-vehicle embedded device 103 by giving an instruction to the in-vehicle diagnosis program based on information acquired from the in-vehicle diagnosis program.

  FIG. 6 is a block diagram showing a hardware configuration of the development PC 101 which is an example of the program generation apparatus according to the third embodiment of the present invention. The development PC 101 includes a CPU (Central Processing Unit) 110, a RAM (Random Access Memory) 120, a ROM (Read Only Memory) 130, an IF unit 140, and a hard disk 150.

  The hard disk 150 is a nonvolatile storage device. The hard disk 150 stores an OS 151, a GUI development tool 152, a DMT management unit 153, a library 154, a filtering rule 155, a conversion rule 156, model compilers 157a to 157c, source programs 158a to 158c, and machine language programs 159a to 159c.

  The GUI development tool 152 includes software for generating a program according to the first embodiment of the invention, and is software for supporting the design of configuration information and node state information by DMT using the GUI. The DMT management unit 153 is a program module including the communication processing information 111, and is, for example, a class in an object-oriented language. The library 154 includes various library functions, class libraries, API (Application Programming Interface), and the like used for the in-vehicle diagnosis program. The filtering rule 155 is information defining a rule for filtering a log. The conversion rule 156 is information defining a rule relating to conversion with the in-vehicle diagnosis protocol used for communication with the control system ECU. Each of the model compilers 157a to 157c is a compiler for generating source code corresponding to a predetermined processor from DMT model information or divided model information. The model compilers 157a to 157c correspond to three information system ECUs included in the in-vehicle embedded device 103 described later. The source programs 158a to 158c are source programs generated by the model compilers 157a to 157c, respectively. The machine language programs 159a to 159c are binary programs compiled from the source programs 158a to 158c, respectively.

  The CPU 110 controls various processes in the development PC 101, access to the RAM 120, the ROM 130, the IF unit 140, the hard disk 150, and the like. The IF unit 140 communicates with the management server 102.

  In the development PC 101, the CPU 110 reads and executes the OS 151, the GUI development tool 152, and the like stored in the RAM 120, the ROM 130, or the hard disk 150. Accordingly, the development PC 101 functions as the configuration information generation unit 12, the node state information generation unit 13, the conversion unit 14, and the program generation unit 15, and can generate an in-vehicle diagnosis program.

  Note that the hardware configuration of the management server 102 only needs to have a wireless communication function with the in-vehicle embedded device 103 and can be realized by a known technique, and thus illustration and description thereof are omitted.

  FIG. 7 is a block diagram showing a configuration of the in-vehicle embedded device 103 according to the third embodiment of the present invention. First, an outline of the in-vehicle embedded device 103 will be described. The in-vehicle embedded device 103 is equipped with a wireless communication module 34. Therefore, the management server 102 can perform remote diagnosis and remote operation of the in-vehicle embedded device 103 via a wireless communication network (not shown). The management server 102 recognizes the in-vehicle embedded device 103 as a single device. Therefore, a single DMT can be used for device management of the in-vehicle embedded device 103.

  The in-vehicle embedded device 103 includes a plurality of information system ECUs 31 to 33 and a plurality of control system ECUs 37 and 38. For this reason, the in-vehicle diagnosis program can be expressed by a single DMT, but it is necessary to perform processing across a plurality of ECUs.

  The control system ECUs 37 and 38 are control and management objects from the management server 102. The control system ECUs 37 and 38 are connected to an information system ECU 33 that cannot communicate directly with the management server 102.

  The information system ECU 31 has a wireless communication function, and the in-vehicle diagnosis program needs to implement communication between information system ECUs via the in-vehicle LANn1.

  The information system ECU 33 and the control system ECUs 37 and 38 are connected to a non-IP (Internet Protocol) in-vehicle LANB such as a CAN (Controller Area Network), and DMT access from the management server 102 is a communication dedicated to the control system ECU. Need to convert to protocol.

  In-vehicle sensors 35 and 36 (GPS (Global Positioning System), gyro sensor, etc.) and applications controlled and managed from the management server 102 are distributed on a plurality of information system ECUs.

  Next, a detailed configuration of the in-vehicle embedded device 103 will be described. The in-vehicle embedded device 103 includes information system ECUs 31 to 33, a wireless communication module 34, sensors 35 and 36, control system ECUs 37 and 38, and in-vehicle LANs n1 and n2. Information system ECU31-33 is mutually connected via vehicle-mounted LANn1. Here, the in-vehicle LAN n1 is a LAN for multimedia information system ECUs such as MOST (Media Oriented Systems Transport). MOST also has a specification that supports TCP / IP communication called MAMAC (MOST Asynchronous Medium Access Control). Here, the in-vehicle LANn1 enables TCP / IP communication by MAMAC.

  The information system ECU 31 controls the wireless communication module 34 and the sensor 35. The information system ECU 31 can communicate with the management server 102 via the wireless communication module 34. The wireless communication module 34 can use, for example, a W-CDMA 3G mobile phone as a communication method and OMA DM as a communication protocol for device management.

  In addition, a device management protocol adapter 411, a DMT access IF 412, an application 413, a DMT management application 416, and applications 417 and 418 are installed in the information system ECU 31 in advance. The information system ECU 31 receives and executes the DMT access IF 414 and the in-vehicle diagnosis program 415 from the management server 102 via the wireless communication module 34. Note that the DMT access IF 414 is added by the development PC 101 or the management server 102.

  In the information system ECU 32, an application 421, a DMT access IF 422, and an application 423 are installed in advance. The information system ECU 32 receives the DMT access IF 424 and the in-vehicle diagnosis program 425 from the information system ECU 31 and executes them.

  The information system ECU 33 controls the sensor 36. The information system ECU 33 controls the control system ECUs 37 and 38 via the in-vehicle LANn2. The in-vehicle LANn2 is a LAN for a control system ECU such as CAN. The information system ECU 33 can access the control system ECUs 37 and 38 using a diagnostic protocol such as LAN for control system ECUs such as CAN or KWP2000. The information system ECU 32 receives the DMT access IF 431 and the in-vehicle diagnosis program 432 from the information system ECU 31 and executes them.

  The in-vehicle diagnosis programs 415, 425, and 432 are applications generated by the development PC 101 and distributed from the management server 102.

  The DMT management application 416 in the information system ECU 31 is an application for managing the in-vehicle DMT, and enables access to the DMT from the management server 102 or another information system ECU (32 or 33).

  The DMT access IFs 412, 414, 422, 424, and 431 are APIs for accessing the DMT in the DMT management application 416 from an application operating on the information system ECU.

  The application 423 linked to the DMT access IF 422, 424 or 431 in the information system ECUs 32 and 33 and the in-vehicle diagnosis program 425 or 432 are connected to the DMT management application 416 in the information system ECU 31 using TCP / IP socket communication or the like. Communicate.

  On the other hand, the applications 417, 418, and 421 that are not linked to the DMT access IFs 412, 414, 422, 424, or 431 can notify the in-vehicle diagnostic programs 415, 425, and 432 of the event in the form of log output.

  A device management protocol adapter 411 on the information system ECU 31 is mounted with a device management protocol such as OMA DM, and serves as an interface between the management server 102 and the DMT management application 416.

  Here, the features of Embodiment 3 of the present invention will be described by dividing them into the following three (1) to (3).

  (1) Embodiment 3 of the present invention can be said to be a mechanism for automatically generating a machine language program to be executed on a plurality of processors in an embedded device based on the node configuration of the DMT and the behavior of each node. .

  (1-1) An arbitrary node of the DMT can have a unique state, and the state of the node itself and the behavior of the node in the state can be described as a state model diagram. The state model diagram will be described later with reference to FIG. The state of the node described on the state model diagram is a special state for describing the behavior of the node. Therefore, it is different from a node state defined by a device management protocol such as OMA-DM. That is, each node can have a plurality of states at the same time.

  In MDA, code is generated based on the UML diagram. However, in the third embodiment of the present invention, code generation is performed based on the DMT model (DMT configuration diagram and node-based state model diagram). Differences from MDA are absorbed by the GUI development tool and DMT manager. This is because the third embodiment of the present invention focuses on remote device management using DMT and has a structure specialized for them.

  In MDA, a state model diagram capable of describing actions is created for each class diagram. However, in Embodiment 3 of the present invention, a state model diagram is created for each DMT node. If the UML is forced to correspond, each node corresponds to a subclass of the node class (FIG. 15) and also corresponds to an instance. That is, the class and instance equivalents are generated at the same time as the node definition at the time of model design. In addition, each node can be handled as either a class or an instance on the action description language, which is the behavior of the state model diagram, and is greatly different from general UML and MDA concepts.

  The introduction of a DMT-based model makes a crucial difference from MDA. That is, it is not necessary to describe logic corresponding to object-oriented life cycle management such as instance creation and deletion for each node on the model.

  In the third embodiment of the present invention, at the same time as the node definition at the time of model design, an asynchronous event corresponding to node access (such as OMA-DM Get, Replace, Exec, etc.) is defined for the defined node. It is possible to assign automatically.

  Furthermore, according to the third embodiment of the present invention, a node entity (instance) is automatically generated / activated on a real machine by receiving a node addition command (such as OMA-DM Add) from the management server. Is possible.

  (1-2) In the case of the in-vehicle embedded device 103 having a plurality of processors, any node in the DMT can be assigned to a specific information system ECU. Based on this information, the source code of the action description part of the diagnostic program for different processors is generated simultaneously. This makes it possible to automatically generate codes for a plurality of information system ECUs from a single DMT.

  The model dividing function of the model compiler divides the model into a plurality of parts in consideration of the node and processor allocation information. The divided model is converted from the model to the source code by the source code conversion function of the model compiler corresponding to each processor. This makes it possible to create a diagnostic program without being conscious of communication between processors.

  Further, the processing related to the inter-processor communication is concealed in “DMT management unit” and “DMT access I / F” in FIG. Therefore, the action description part of the information system ECU 31 can perform communication between ECUs only by accessing (= reading / writing) the node assigned to the information system ECU 32.

  (1-3) It is possible to describe the behavior of a node in an action description language on a DMT-based state model diagram. Furthermore, it is possible to generate an event corresponding to a parameter defined in a script written in an in-vehicle diagnosis description language (such as ASAM-MCD2 ODX) and an access event (synchronous or asynchronous) to the DMT.

  (2) Embodiment 3 of the present invention can be said to be a method for configuring an automatically generated machine language program.

  (2-1) The generated machine language program is a binary program that is composed of a “DMT management unit” and an “action description unit” and is executed on the in-vehicle embedded device 103. This binary program can include a “control system ECU on-board diagnostic protocol conversion unit” and a “log filtering processing unit” as additional functions.

  FIG. 8 is a diagram showing the concept of the in-vehicle diagnostic program generated according to the third embodiment of the present invention. The DMTd5 is tree structure data for device management of the diagnosis target in-vehicle embedded device 103 generated in the development PC 101. The development PC 101 can assign each node process in the DMTd5 to a different information system ECU. Here, among each node in the DMTd5, a node group assigned to the information system ECU 33 is a divided DMTd51, and a node group assigned to the information system ECU 32 is a divided DMTd52. The development PC 101 divides the DMTd5 into the divided DMTd51 and the divided DMTd52 by the GUI development tool.

  The DMT access IF 521 and the application 522 are applications of the information system ECU 32 corresponding to the divided DMTd 52. The application of the information system ECU 32 can receive a notification from the management server 102 or another information system ECU as a DMT event via the DMT access I / F. The DMT access IF 521 may be a plug-in I / F.

  The in-vehicle diagnosis program 51 is an in-vehicle diagnosis program for the information system ECU 33 corresponding to the divided DMTd 51. The in-vehicle diagnosis program 51 includes a DMT access IF 511, a DMT management unit 512, an action description unit 513, a log filtering processing unit 514, a filtering rule 515, a conversion rule 516, and a control system ECU in-vehicle diagnosis protocol conversion unit 517.

  The action description part 513 is a part corresponding to a program code generated based on action information defined in the state model diagram. The action description part 513 is a functional part composed of a machine language automatically generated from DMT model information. Here, an action for an event that occurs in the DMT management unit 512, the log filtering processing unit 514, or the like is described. From the action description section 513, a function of a library function 53 that can be dynamically linked and operates in the same processor can be called.

  By accessing the DMT node from the action description unit 513, it is possible to provide feedback to other applications operating on the management center or information system ECU on the wireless network. For example, the DMT access IF 511 is linked to the feedback processing target application.

  The DMT management unit 512, the control system ECU in-vehicle diagnosis protocol conversion unit 517, and the log filtering processing unit 514 are provided as libraries. Thereby, the logic peculiar to the in-vehicle embedded device 103 is concealed. Therefore, the service engineer describes only the action information that is the source for generating the action description part 513. And each function part is linked mutually and becomes one binary.

  The DMT management unit 512 is a functional unit that provides an interface between the divided DMTd 51 and the action description unit 513. Then, the DMT management unit 512 can cause the action description unit 513 to generate an event. In addition, the DMT management unit 512 can absorb differences in access methods to the DMT.

  Here, there are the following two methods for accessing the DMT. According to the third embodiment of the present invention, a plurality of DMT access means can be expressed by one script.

  (Method 1) After the DMT access by the local program in the management server 102 or the information system ECU, the access content is immediately reflected in the DMT itself. Thereby, it can be used for in-vehicle diagnosis that requires high real-time performance.

  (Method 2) Immediately after the DMT access by the local program in the management server 102 or the information system ECU, the access content is not reflected in the DMT, but the access content is reflected in the commit command. It also supports rollback instructions. For example, when one diagnosis function is composed of a plurality of related nodes, it can be used for synchronization between nodes.

  This is because the DMT management unit 512 differs from the node access based on the access to the DMT node (GET or REPLACE command or COMMIT or ROLLBACK command) from the device management system that supports the protocol such as OMA-DM. This is because an asynchronous event for the action description part 513 is generated.

  FIG. 9 is a diagram showing an example of DMT access management in the method 2 according to the third embodiment of the present invention. Here, a DMT access from the DMT management application 416 to the in-vehicle diagnosis program 51 is taken as an example. The in-vehicle diagnosis program 51 includes at least a DMT management unit 512, a node data management unit 512a, and an action description unit 513.

  First, the DMT management application 416 transmits a REPLACE command for the node A to the DMT management unit 512 (S301). Then, the DMT management unit 512 notifies the node data management unit 512a to that effect (S302). Next, the DMT management application 416 transmits a REPLACE command for the node B to the DMT management unit 512 (S303). Then, the DMT management unit 512 notifies the node data management unit 512a to that effect (S304). However, at this time, the DMT management unit 512 does not notify the action description unit 513 of an event.

  Then, the DMT management application 416 transmits a COMMIT command to the DMT management unit 512 (S305). Accordingly, the node data management unit 512a transmits a REPLACE command for the node A to the action description unit 513 (S306). Subsequently, the node data management unit 512a transmits a REPLACE command for the node B to the action description unit 513 (S307). That is, the action description unit 513 updates the nodes A and B with new data using the COMMIT instruction as a trigger. The data before update is backed up in the DMT manager 512.

  Thereafter, the DMT management application 416 transmits a ROLLBACK command to the DMT management unit 512 (S308). Accordingly, the node data management unit 512a transmits a REPLACE command for the node A to the action description unit 513 (S309). Subsequently, the node data management unit 512a transmits a REPLACE command for the node B to the action description unit 513 (S310). That is, the action description unit 513 returns the nodes A and B to the data before update using the ROLLBACK command as a trigger.

  Returning to FIG. By using the DMT management unit 512, it is not necessary for the service engineer to describe any communication processing with the management center or other information system ECUs.

  The control system ECU in-vehicle diagnosis protocol conversion unit 517 converts the generated event into a sequence process using an in-vehicle diagnosis protocol for the control system ECU such as KWP2000 based on the conversion rule 516 described in the in-vehicle diagnosis description language. It is a functional part to do. The control system ECU in-vehicle diagnosis protocol conversion unit 517 is connected to the MVCI Protocol Stack & in-vehicle LAN driver 542 via the D-PDU API 541. The D-PDU API 541 is connected to the control system ECUs 551 to 553 by an in-vehicle LAN such as CAN.

  The log collection function 56 collects logs of applications that operate on a plurality of information system ECUs. The log filtering processing unit 514 is a functional unit that analyzes logs collected by a log collecting function 56 from a plurality of processors using a filtering rule 515 and generates an event for the action description unit 513. Since the technique for filtering the log is a known technique, detailed description thereof is omitted.

  (3) Embodiment 3 of the present invention can be referred to as a GUI development tool and a model compiler corresponding to the above means.

  (3-1) A DMT-based model can be created from simple work (drag and drop, etc.) on the development tool on the GUI development tool. Furthermore, log filtering rules, in-vehicle diagnostic protocol conversion rules for control ECUs, and DMT-based models can be linked.

(3-2) A model compiler that converts a single DMT-based model into source code such as C language or C ++ language can be used in the GUI development tool. The model compiler defined here includes the following three functions.
(3-2-1) A function capable of dividing a single DMT model into a plurality of models (such as UML) that can be automatically generated in units of processors.
(3-2-2) A function that can automatically generate source code specialized for the system configuration (system call, memory map, etc.) of each processor from a divided model (such as UML).
(3-2-3) A function of automatically converting access to a node on the DMT model into access to a class library in the DMT management unit 512.

  Next, the concept of the GUI development tool according to the third embodiment of the present invention will be described with reference to FIG. First, the development PC 101 receives, from a user, a position and a hierarchical relationship between the nodes by dragging and dropping when the functional configuration in the in-vehicle embedded device 103 to be diagnosed is expressed by a node. Then, the development PC 101 generates DMT model information expressed in a hierarchical structure from the relationship between the received node position and hierarchy (S31). The development PC 101 may accept existing DMT model information by importing.

  Next, the development PC 101 receives an assignment of an information system ECU from a user to an arbitrary node. Then, the development PC 101 sets the received information system ECU as assignment information in the node, that is, as a property value (S32). At this time, the development PC 101 may accept the property value from another window.

  Subsequently, the development PC 101 accepts selection of an arbitrary node from the user by a mouse click or the like. At this time, the development PC 101 displays a state model diagram creation screen in a separate window (S33). Here, the development PC 101 receives the state of the selected node and the action information that is the behavior of the node in the state. Then, the development PC 101 displays a state model diagram from the received state and action information to obtain node state information.

  Further, the development PC 101 can create an event understandable by the action description unit 513 from the log in the node (S34). The log is an example of a processing result of an application that operates on a plurality of processors. And the rule which processes a log can be linked | related with the said node.

  Further, the development PC 101 can describe the association between the event issued by the action description unit 513 and the in-vehicle diagnosis protocol in the node (S35). The in-vehicle diagnosis protocol is an example of a rule for performing communication with a control device that is mounted on an embedded device and controlled by a plurality of processors. And the conversion rule of a vehicle-mounted diagnostic protocol can be linked | related with the said node. Further, the development PC 101 can cope with import and export of in-vehicle diagnostic languages such as ODX.

  Further, the development PC 101 can capture the state model diagram from the provided library (including the in-vehicle diagnosis library) and the event list by selecting with the mouse (S36). Further, the development PC 101 can create a part of user-defined libraries used in the node (S37). Thereby, it becomes possible to cooperate with the node model created by MDA.

  FIG. 11 is a diagram illustrating an example of a state model diagram and an action description language according to the third exemplary embodiment of the present invention. Note that the action description language used in FIG. 11 is an improvement to the one for Executable UML. However, the action description language according to the third exemplary embodiment of the present invention may not be based on Executable UML.

  Further, the DMT session in FIG. 11 refers to a unit of virtual connection established on a one-to-one basis between the application on the information system ECU and the DMT management application 416 in the in-vehicle embedded device 103. For example, when a DMT session whose root node is “./Device” is established between the in-vehicle diagnostic program generated by the development PC 101 and the DMT management application 416, the subordinate node (“./Device/NodeA” The occurrence of a DMT event is permitted.

FIG. 11 shows an example in which the behavior of the DMT node “./OMADM/DiagMon/Battery/Level” is described. The processing flow is as follows.
(1) When a DMT session having “./OMADM/DiagMon/Battery” as a root node is opened, a fixed-cycle timer having a value described in “./OMADM/DiagMon/Battery/Cycle” is started.
(2) The remaining battery level is read by interrupt processing of the fixed-cycle timer.
(3) When a GET command for “./OMADM/DiagMon/Battery/Level” is issued from the management center while the DMT session is open, the value of the remaining battery level is returned to the management center.

  Next, the action description language described in FIG. 11, that is, action information will be briefly described. First, "Select Cycle from Node where selected.URL =" ./ OMADM / DiagMon / Baterry / Cycle "" means the node "Cycle" whose URL is "./OMADM/DiagMon/Baterry/Cycle" from the node class. Indicates that is to be selected. “TIM: TimerStart (Cycle. NodeValue, timer interrupt processing in progress);” indicates that the fixed-cycle timer is started. “Generate“ DMT session open state transition notification ”” indicates that an asynchronous event “DMT session open state transition notification” is issued.

  Subsequently, the node B operating on the in-vehicle diagnosis program 425 in the information system ECU 32 issues a Replace event (= rewrites the value of the node) to the node A operating on the in-vehicle diagnosis program 432 in the information system ECU 33. An example of this will be described with reference to the sequence diagrams of FIGS.

  FIG. 12 is a sequence diagram showing a flow of processing of the in-vehicle diagnosis program for the information system ECU 33 according to the third embodiment of the present invention. Here, processing including inter-processor communication between the DMT management application 416 in the information system ECU 31 and the in-vehicle diagnosis program 432 in the information system ECU 33 is shown. The automatic addition portion 61 is processing related to class definition, instance generation, and node registration in the DMT management unit. In the UML-based MDA, the user has to describe the automatic addition portion 61 as well. However, in the third embodiment of the present invention, only the processing of the mounting portion 62 need only be described by action information.

  FIG. 13 is a sequence diagram showing a flow of processing of the in-vehicle diagnosis program for the information system ECU 32 according to the third embodiment of the present invention. Here, processing including inter-processor communication between the DMT management application 416 in the information system ECU 31 and the in-vehicle diagnosis program 425 in the information system ECU 32 is shown. The automatic addition portion 63 is processing related to class definition, instance generation, and node registration in the DMT management unit. In the UML-based MDA, the user has to describe the automatic addition portion 63 as well. However, in the third embodiment of the present invention, it is only necessary to describe only the processing of the mounting portion 64 by action information.

  In normal MDA, a UML model must be created for each of the in-vehicle diagnosis program 432 in the information system ECU 33 and the in-vehicle diagnosis program 425 in the information system ECU 32. However, in Embodiment 3 of the present invention, operations on a plurality of information system ECUs can be expressed on one DMT.

In the third embodiment of the present invention, it is assumed that source codes and binaries having substantially the same configuration are generated using the following two software development techniques.
(1) Automatic code generation using MDA (In the third embodiment, it is assumed that a UML model is converted into a source code of an object-oriented language C ++ language.)
(2) Automatic code generation using the present invention (In the third embodiment, it is assumed that a DMT-based model is converted into C ++ language source code, which is an object-oriented language.)

  FIG. 14 is a diagram illustrating an example of a state model diagram according to the third embodiment of the present invention. Here, two states of “initial state” and “Replace event processing” are defined as states of a certain node, and action information “set value X to node A” is defined for each. Show. When a Replace event is received, the process transits to “Replace event processing in progress”. That is, the third embodiment of the present invention indicates that software with a complicated sequence can be described with only a small amount of description as shown in FIG.

  FIG. 15 is a diagram illustrating an example of a class diagram in the case of designing with related technology. The class diagram in FIG. 15 is a class diagram showing a node class and a relationship with the node A and the node B. However, this class diagram is a case where DMT-based automatic generation is forcibly brought into MDA, and it becomes a less desirable form for UML modeling.

  It should be noted that, as an example of UML modeling, it is originally desirable to describe as shown in FIG. FIG. 16 is a diagram illustrating an example of UML modeling in the case of designing with related technology. In this case, node A and node B are not extracted as classes in the first place. However, describing the behavior that can generate automatic code from FIG. 16 requires a fairly advanced object-oriented technique, and cannot solve the problem targeted by the present invention.

  FIG. 17 is a diagram showing a concept of device management using the DMT according to the third embodiment of the present invention. First, the protocol adapter application 571 and the DMT control application 572 can access each node of the DMT in the in-vehicle embedded device 103 from the management server 102 via the wireless communication module 34. When a designated node is accessed, an event notification can be received.

  The plug-in application 573 is a battery remaining amount detection application assigned to the node “./Device/Battery”. When there is an access to a node, the plug-in application 573 is notified of an event. Therefore, local applications in the management server 102 and the in-vehicle embedded device 103 can perform Add / Get / Replace / Exec on each node.

  From the above, the effects of the third embodiment of the present invention are as follows. First, even a service engineer who is not a developer can easily create a diagnostic program that handles a plurality of information system ECUs and control system ECUs. By adopting an automatic code generation method arranged for in-vehicle embedded devices according to the present invention, it becomes unnecessary to learn system dependent parts (programming language, OS, etc.) of each ECU. Also, the coding process can be omitted. In addition, the control I / F related to in-vehicle technologies such as OMA DM and in-vehicle diagnosis is provided as a library that can be linked with the “action description part”, so the specifications of each technology and related middleware can be specified for programming. Time to learn can be shortened.

  Furthermore, it is only necessary to know the operation of the DMT node configuration and access to the node, and it is not necessary to know details such as the communication sequence of the OMA DM. Since codes of a plurality of information system ECUs can be automatically generated from one DMT tree, it is not necessary to design and code communication between information system ECUs. Further, it is only necessary to specify the association between the node and the information system ECU, that is, the assignment.

  Even when access to each node of the DMT is performed from a plurality of applications by different access methods, it is possible to cope with only one procedure. The difference in DMT access methods is because it can be absorbed by the “DMT management unit”. There is also an advantage that the action description part does not need to be aware of rollback processing at all.

  As described above, according to the third embodiment of the present invention, a program to be executed on an embedded device can be easily generated without requiring a wide range of expertise in the embedded device having a plurality of processors and realizing a predetermined function. can do.

<Other embodiments of the invention>
DMT Admin is a specification of a package for accessing DMT from a Java (registered trademark) application corresponding to OSGi defined by OSGi R4 mobile and JSR232. With DMT Admin, it is possible to share the same node from multiple Java applications. However, DMT Admin is a highly complex API although it is highly functional.

  There is ASAM-MCD2 ODX as an XML (Extensible Markup Language) -based in-vehicle diagnostic language for control system ECUs that have been converted to ISO (International Organization for Standardization). ASAM-MCD2 ODX describes rules for converting a certain command into an in-vehicle diagnostic protocol such as KWP2000.

  Any wireless communication technology can be used for the technology for transferring the program generated by the present invention to the information system ECU in the embedded device via wireless and the technology for transmitting the log and diagnostic information to the management center. Note that there is G-BOOK (registered trademark) as an in-vehicle wireless communication service. However, in G-BOOK or the like, the program generated according to the present invention cannot be transferred to the information system ECU in the embedded device via wireless communication.

  Furthermore, the present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the gist of the present invention described above. For example, in the above-described embodiment, the present invention has been described as a hardware configuration, but the present invention is not limited to this. The present invention can also realize arbitrary processing by causing a CPU (Central Processing Unit) to execute a computer program. In this case, the computer program can be stored using various types of non-transitory computer readable media and supplied to the computer.

  Non-transitory computer readable media include various types of tangible storage media. Examples of non-transitory computer-readable media include magnetic recording media (for example, flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (for example, magneto-optical disks), CD-ROMs (Read Only Memory), CD-Rs, CD-R / W, DVD (Digital Versatile Disc), BD (Blu-ray (registered trademark) Disc), semiconductor memory (for example, mask ROM, PROM (Programmable ROM), EPROM (Erasable PROM), flash ROM, RAM ( Random Access Memory)). The computer program may also be supplied to the computer by various types of transitory computer readable media. Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves. The temporary computer-readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.

  A part or all of the above embodiments can be described as in the following supplementary notes, but is not limited thereto.

(Additional remark 1) The memory | storage means which memorize | stores beforehand the communication processing information which is a program module by which the communication processing between the said some processor was mounted in the built-in apparatus which implement | achieves a predetermined function in which a some processor is mounted,
Configuration information generating means for generating configuration information in which the configuration of the predetermined function in the embedded device is defined by a plurality of nodes;
Node state information generating means for generating, for each of a plurality of nodes defined in the configuration information, node state information that defines a node state and action information that is a behavior of the node in the state;
Conversion means for converting from action information defined in the node state information into a program code that realizes processing corresponding to the behavior of the node in the state of the node;
Based on the configuration information, a program generation unit that generates a plurality of programs corresponding to each of the plurality of processors, including the communication processing information stored in the storage unit and the converted program code;
A program generation apparatus comprising:

(Supplementary Note 2) The configuration information generation means generates the configuration information including allocation information in which any of the plurality of processors is allocated to each node.
The program generating means generates a plurality of post-classification configuration information by classifying each node into one of the plurality of allocated processors based on the allocation information included in the configuration information, and The program generation apparatus according to appendix 1, wherein the plurality of programs are generated from the post-classification configuration information.

(Additional remark 3) It further has a plurality of model compilers which generate a program corresponding to each of the plurality of processors,
The program generation means identifies a corresponding processor from the classified configuration information, selects a model compiler corresponding to the identified processor, and uses the selected model compiler to identify the processor from the classified configuration information. The program generation device according to attachment 2, wherein the program generation device generates an executable program.

  (Supplementary note 4) The program generation device according to any one of Supplementary notes 1 to 3, wherein the program generation unit further includes an asynchronous event corresponding to node access when generating the plurality of programs. .

  (Additional remark 5) The said structure information production | generation means uses DMT (Device Management Tree) as said structure information, The program generation apparatus of any one of Additional remark 1 thru | or 4 characterized by the above-mentioned.

  (Additional remark 6) The said node state information production | generation means associates the rule which processes the process result of the application which operate | moves on the said several processor with the said node state information, Any one of Additional remark 1 thru | or 5 characterized by the above-mentioned. The program generation device described in 1.

  (Supplementary note 7) The node state information generation means associates the node state information with a rule for communicating with a control device mounted on the embedded device and controlled by the plurality of processors. The program generation device according to any one of appendices 1 to 6.

(Supplementary Note 8) Generate configuration information in which a plurality of processors are mounted and a configuration of the predetermined function in an embedded device that realizes a predetermined function is defined by a plurality of nodes,
For each of a plurality of nodes defined in the configuration information, generate node state information that defines a node state and action information that is a behavior of the node in the state,
The action information defined in the node state information is converted into a program code that realizes processing corresponding to the behavior of the node in the state of the node,
Based on the configuration information, a plurality of programs corresponding to each of the plurality of processors includes communication processing information that is a program module in which communication processing between the plurality of processors is implemented, and the converted program code. Generate,
Program generation method.

(Supplementary Note 9) Generate the configuration information including allocation information in which any of the plurality of processors is allocated to each node,
Based on the allocation information included in the configuration information, each node is classified into one of the plurality of allocated processors to generate a plurality of post-classification configuration information, and from the generated plurality of post-classification configuration information The program generation method according to appendix 8, wherein the plurality of programs are generated.

(Supplementary Note 10) Identify the corresponding processor from the post-classification configuration information,
Selecting a model compiler corresponding to the identified processor from a plurality of model compilers that generate a program corresponding to each of the plurality of processors;
The program generation method according to appendix 9, wherein a program executable by the specified processor is generated from the post-classification configuration information using the selected model compiler.

  (Supplementary note 11) The program generation method according to any one of supplementary notes 8 to 10, further comprising an asynchronous event corresponding to node access when generating the plurality of programs.

  (Supplementary note 12) The program generation method according to any one of supplementary notes 8 to 11, wherein a DMT (Device Management Tree) is used as the configuration information.

  (Supplementary note 13) The program generation method according to any one of Supplementary notes 8 to 12, wherein a rule for processing a processing result of an application operating on the plurality of processors is associated with the node state information.

  (Supplementary note 14) Any one of Supplementary notes 8 to 13, wherein the node state information is associated with a rule for communicating with a control device mounted on the embedded device and controlled by the plurality of processors. The program generation method according to claim 1.

(Supplementary Note 15) Accepts definitions by a plurality of nodes of a configuration of a predetermined function in an embedded device that is mounted with a plurality of processors and implements a predetermined function,
Generate configuration information based on the accepted definition,
Accepting any one of a plurality of nodes included in the configuration information;
Accept the definition of the state of the node in the specified node and the action information that is the behavior of the node in the state,
Generate node state information based on the received state of the node and the action information path,
The action information defined in the node state information is converted into a program code that realizes processing corresponding to the behavior of the node in the state of the node,
Obtaining communication processing information which is a program module in which communication processing between the plurality of processors stored in advance in the storage unit is implemented;
Based on the configuration information, a plurality of programs corresponding to the plurality of processors are generated including the acquired communication processing information and the converted program code.
A program generation program that causes a computer to execute processing.

(Supplementary Note 16) Generate the configuration information including allocation information in which any of the plurality of processors is allocated to each node,
Based on the allocation information included in the configuration information, each node is classified into one of the plurality of allocated processors to generate a plurality of post-classification configuration information, and from the generated plurality of post-classification configuration information The program generation program according to appendix 15, wherein the plurality of programs are generated.

(Supplementary note 17) Identify the corresponding processor from the classified configuration information,
Selecting a model compiler corresponding to the identified processor from a plurality of model compilers that generate a program corresponding to each of the plurality of processors;
17. The program generation program according to appendix 16, wherein a program executable by the specified processor is generated from the post-classification configuration information using the selected model compiler.

  (Supplementary note 18) The program generation program according to any one of supplementary notes 15 to 17, further comprising an asynchronous event corresponding to node access when generating the plurality of programs.

  (Supplementary note 19) The program generation program according to any one of supplementary notes 15 to 18, wherein a DMT (Device Management Tree) is used as the configuration information.

  (Supplementary note 20) The program generation program according to any one of supplementary notes 15 to 19, wherein a rule for processing a processing result of an application operating on the plurality of processors is associated with the node state information.

  (Supplementary note 21) Any one of supplementary notes 15 to 20, wherein a rule for communicating with a control device mounted on the embedded device and controlled by the plurality of processors is associated with the node state information. The program generation program according to claim 1.

(Supplementary Note 22) An embedded device that includes a plurality of processors including a processor capable of wireless communication with the outside and implements a predetermined function;
Storage means for preliminarily storing communication processing information which is a program module in which communication processing among the plurality of processors is implemented;
Configuration information generating means for generating configuration information in which the configuration of the predetermined function in the embedded device is defined by a plurality of nodes;
Node state information generating means for generating, for each of a plurality of nodes defined in the configuration information, node state information that defines a node state and action information that is a behavior of the node in the state;
Conversion means for converting from action information defined in the node state information into a program code that realizes processing corresponding to the behavior of the node in the state of the node;
Based on the configuration information, a program generation unit that generates a plurality of programs corresponding to each of the plurality of processors, including the communication processing information stored in the storage unit and the converted program code;
Remote control means for controlling the embedded device by wireless communication;
A remote management device comprising:
The remote control means transmits the generated plurality of programs to the embedded device,
The embedded device causes each of the plurality of programs received from the remote management device to be executed by a corresponding processor among the plurality of processors,
The plurality of processors performs processing based on the converted program code included in a program executed by each processor, and performs communication between the processors based on communication processing included in the program. Remote management system.

DESCRIPTION OF SYMBOLS 1 Program generation apparatus 11 Memory | storage part 111 Communication processing information 12 Configuration information generation part 13 Node state information generation part 14 Conversion part 15 Program generation part 10 Remote management system 1a Remote management apparatus 16 Remote control part 2 Embedded equipment 21a Processor 21b Processor 21n Processor 100 Remote in-vehicle diagnostic system 101 Development PC
110 CPU
120 RAM
130 ROM
140 IF unit 150 hard disk 151 OS
152 GUI Development Tool 153 DMT Management Unit 154 Library 155 Filtering Rule 156 Conversion Rule 157a Model Compiler 157b Model Compiler 157c Model Compiler 158a Source Program 158b Source Program 158c Source Program 159a Machine Language Program 159b Machine Language Program 159c Machine Language Program 102 Management Server 103 In-vehicle embedded equipment 31 Information system ECU
32 Information ECU
33 Information system ECU
34 Wireless communication module 35 Sensor 36 Sensor 37 Control system ECU
38 Control system ECU
n1 In-vehicle LAN
n2 Car LAN
411 Device management protocol adapter 412 DMT access IF
413 Application 414 DMT access IF
415 In-vehicle diagnostic program 416 DMT management application 417 application 418 application 421 application 422 DMT access IF
423 Application 424 DMT access IF
425 On-board diagnostic program 431 DMT access IF
432 On-board diagnostic program d5 DMT
d51 Split DMT
d52 Split DMT
51 In-vehicle diagnostic program 511 DMT access IF
512 DMT management unit 512a Node data management unit 513 Action description unit 514 Log filtering processing unit 515 Filtering rule 516 Conversion rule 517 Control system ECU in-vehicle diagnosis protocol conversion unit 521 DMT access IF
522 Application 53 Library function 541 D-PDU API
542 MVCI Protocol Stack & Car LAN Driver 551 Control System ECU
552 Control system ECU
553 Control system ECU
56 Log collection function 571 Protocol adapter application 572 DMT control application 573 Plug-in application 61 Automatic addition part 62 Implementation part 63 Automatic addition part 64 Implementation part SC1 source code SC2 source code

Claims (10)

A storage unit that stores in advance communication processing information that is a program module in which communication processing between the plurality of processors is implemented in an embedded device that is provided with a plurality of processors and implements a predetermined function;
Configuration information generating means for generating configuration information in which the configuration of the predetermined function in the embedded device is defined by a plurality of nodes;
Node state information generating means for generating, for each of a plurality of nodes defined in the configuration information, node state information that defines a node state and action information that is a behavior of the node in the state;
Conversion means for converting from action information defined in the node state information into a program code that realizes processing corresponding to the behavior of the node in the state of the node;
Based on the configuration information, a program generation unit that generates a plurality of programs corresponding to each of the plurality of processors, including the communication processing information stored in the storage unit and the converted program code;
A program generation apparatus comprising: The configuration information generation means generates the configuration information including allocation information in which any of the plurality of processors is allocated to each node,
The program generating means generates a plurality of post-classification configuration information by classifying each node into one of the plurality of allocated processors based on the allocation information included in the configuration information, and The program generation apparatus according to claim 1, wherein the plurality of programs are generated from the post-classification configuration information. A plurality of model compilers for generating a program corresponding to each of the plurality of processors;
The program generation means identifies a corresponding processor from the classified configuration information, selects a model compiler corresponding to the identified processor, and uses the selected model compiler to identify the processor from the classified configuration information. The program generating apparatus according to claim 2, wherein an executable program is generated.   4. The program generation apparatus according to claim 1, wherein the program generation unit further includes an asynchronous event corresponding to node access when generating the plurality of programs. 5.   5. The program generation apparatus according to claim 1, wherein the configuration information generation unit uses a DMT (Device Management Tree) as the configuration information. 6.   The said node state information generation means associates the rule which processes the process result of the application which operate | moves on the said several processor with the said node state information, The any one of Claim 1 thru | or 5 characterized by the above-mentioned. Program generator.   The node state information generation unit associates a rule for communicating with a control device mounted on the embedded device and controlled by the plurality of processors, with the node state information. The program generation device according to any one of 1 to 6. A configuration information in which a plurality of processors are installed and a configuration of the predetermined function in an embedded device realizing a predetermined function is defined by a plurality of nodes,
For each of a plurality of nodes defined in the configuration information, generate node state information that defines a node state and action information that is a behavior of the node in the state,
The action information defined in the node state information is converted into a program code that realizes processing corresponding to the behavior of the node in the state of the node,
Based on the configuration information, a plurality of programs corresponding to each of the plurality of processors includes communication processing information that is a program module in which communication processing between the plurality of processors is implemented, and the converted program code. Generate,
Program generation method. Accepts definitions by multiple nodes of the configuration of the predetermined function in an embedded device that has multiple processors and implements the predetermined function,
Generate configuration information based on the accepted definition,
Accepting any one of a plurality of nodes included in the configuration information;
Accept the definition of the state of the node in the specified node and the action information that is the behavior of the node in the state,
Generate node state information based on the received state of the node and the action information path,
The action information defined in the node state information is converted into a program code that realizes processing corresponding to the behavior of the node in the state of the node,
Obtaining communication processing information which is a program module in which communication processing between the plurality of processors stored in advance in the storage unit is implemented;
Based on the configuration information, a plurality of programs corresponding to the plurality of processors are generated including the acquired communication processing information and the converted program code.
A program generation program that causes a computer to execute processing. An embedded device having a plurality of processors including a processor capable of wireless communication with the outside and realizing a predetermined function;
Storage means for preliminarily storing communication processing information which is a program module in which communication processing among the plurality of processors is implemented;
Configuration information generating means for generating configuration information in which the configuration of the predetermined function in the embedded device is defined by a plurality of nodes;
Node state information generating means for generating, for each of a plurality of nodes defined in the configuration information, node state information that defines a node state and action information that is a behavior of the node in the state;
Conversion means for converting from action information defined in the node state information into a program code that realizes processing corresponding to the behavior of the node in the state of the node;
Based on the configuration information, a program generation unit that generates a plurality of programs corresponding to each of the plurality of processors, including the communication processing information stored in the storage unit and the converted program code;
Remote control means for controlling the embedded device by wireless communication;
A remote management device comprising:
The remote control means transmits the generated plurality of programs to the embedded device,
The embedded device causes each of the plurality of programs received from the remote management device to be executed by a corresponding processor among the plurality of processors,
The plurality of processors performs processing based on the converted program code included in a program executed by each processor, and performs communication between the processors based on communication processing included in the program. Remote management system.

Images