JP6322631B2 - Embedded software development method, programming device and embedded device - Google Patents

Description

This invention relates to a method development of embedded software incorporated in the embedded device, on programming device and embedded devices.

  In general-purpose software development, various documents such as specifications, manuals, software designs, source codes, test specifications, etc. are created. In the development process (flow), after creating specifications (test specifications, manuals), creating software design documents, creating source code, compiling in the actual environment, It is supposed to work, verify, and fix bugs.

  In creating the above-mentioned various documents, there has been proposed a specification management device that creates an accurate document by managing data of each process such as determination, registration, and update of system and software specifications using a database. . This specification management device classifies the relationship between deliverables and deliverables created in each process into four types: model elements, relationships between model elements, documents and their configurations, and relationships between model elements and document elements. By defining and registering, the document is automatically generated based on the input model element information and the predefined document information (for example, see Patent Document 1 below).

JP 2006-106893 A

  However, conventionally, in each process of development, since different workers share the work, the cooperation between the different processes cannot be smoothly performed. In addition, the accuracy of each document is affected by the level of proficiency of the workers in each process, and there is a problem that low-accuracy documents created by unskilled workers affect other processes (overall). . For example, the programming of the linkage portion between software requires work by a programmer having a certain knowledge, and this programmer is not familiar with the work of other processes.

  For this reason, between workers in different processes, it is not possible to quickly respond to design, change, etc., and the number of man-hours for cooperation increases, and the total man-hours and costs increase easily. For example, GUI development and control development are performed in separate processes, and the cooperation between the components on the GUI screen and the control processing is manually associated one by one. For this reason, it takes much time and effort to link the components on the GUI screen with the control processing.

  The technique of Patent Document 1 cannot flexibly cope with design, change, and the like because the work state in a certain process cannot be output in an easy-to-understand manner when viewed from an operator in another process. As a result, the workers in each process cannot grasp the overall development state and the cooperation state between the processes, and thus cannot smoothly develop the process in charge.

  In recent years, in addition to general-purpose applications such as PCs, embedded software that operates specific applications has emerged. In such embedded software, the interface between the software has been programmed by a skilled programmer to prepare API functions and call each other between the software.

  The embedded software is a specific simple function such as a remote controller, digital camera, IC recorder, etc., and it is desired that the software can be developed more efficiently without being limited to a skilled programmer.

  If you can develop embedded software even if you are not proficient in programming, and you can create a document that can link each process, you can develop embedded software more efficiently.

  In view of the above problems, an object of the present invention is to efficiently develop embedded software.

To achieve the above object, the development process of embedded software of the present invention, by a processor of the programming device, the data of the first program and the second program embedded software function module by a plurality of programs of the embedded device executes processing feed For acceptance, the OS of the embedded device provides the first address of the data area that the first program passes to the second program and the second address of the data area that the second program passes to the first program. Setting in the virtual memory interface, setting the functions of the first program and the second program that are activated by writing and reading data with respect to an address in advance in the virtual memory area of the virtual memory interface, performing the processing, and the embedded device The CPU Set by ming apparatus, by the first program, write the data to be passed to the second program to the first address of the virtual memory interface, by the second program, the data written to the first address read, write the data of the return value of performing predetermined processing on the second address, by the first program, for reading the data of the written return value to the second address, CPU before Symbol embedded devices, the function calls of the second program corresponding to the written address and data by the first program, the second program, reading the write data, and performs processing.

In addition, the CPU of the embedded device monitors the writing of the data to the first address of the virtual memory interface by the execution process of the second program at regular intervals, and the first address according to the writing of the data The data written in is read.

Further, the OS of the embedded device notifies the second program of writing of the data to the first address of the virtual memory interface, and the second program responds to the notification from the OS. The data written in the address is read.

The programming device of the present invention is a programming device that develops embedded software of an embedded device, and is used for data transmission / reception of a first program and a second program of a plurality of programs for each functional module executed by the embedded device. The virtual memory interface that the OS of the embedded device provides a first address of a data area that the first program passes to the second program and a second address of a data area that the second program passes to the first program And a control unit that performs processing for setting the functions of the first program and the second program that are activated by writing and reading data with respect to an address in advance in the virtual memory area of the virtual memory interface. Features.

Further, the embedded device of the present invention provides a first address of a data area that the first program passes to the second program for data transmission / reception of the first program and the second program of the plurality of programs for each functional module of the embedded software. And a second address of a data area that the second program passes to the first program, a virtual memory interface provided by the OS, and data for the address in advance in the virtual memory area of the virtual memory interface Based on the settings of the functions of the first program and the second program that are activated by writing and reading the data, the first program writes data to be passed to the second program to the first address of the virtual memory interface By the second program, The data written in the first address is read, the return value data subjected to predetermined processing is written in the second address, and the return value data written in the second address by the first program. And a control unit that performs a process of calling the function of the second program corresponding to the address and data written by the first program and reading the written data by the second program. It is characterized by.

  According to the above configuration, for data exchanged between programs, an address to be written by each program and an address to be read are set in the virtual memory interface. As a result, each program can read this data and execute the program based on the data write to the corresponding address of the virtual memory interface. Each program can establish cooperation between programs only by a memory read / write operation.

  According to the present invention, it is possible to efficiently develop embedded software.

FIG. 1 is a diagram for explaining the interface specifications of the embedded software according to the first embodiment. FIG. 2 is a diagram of memory contents of the virtual memory interface according to the first embodiment. FIG. 3 is a flowchart of the contents of data transmission / reception processing using the virtual memory interface according to the first embodiment. FIG. 4 is a diagram illustrating a cooperation example of programs according to the first embodiment. FIG. 5 is a diagram for explaining a method of executing mutual program processing by data change due to polling according to the first embodiment. FIG. 6 is a diagram for explaining a method of executing mutual program processing by event processing according to the first embodiment. FIG. 7 is a diagram for explaining a method for executing mutual program processing via the hardware according to the first embodiment. FIG. 8 is a block diagram of a hardware configuration example of a programming device used for embedded software development according to the first embodiment. FIG. 9 is a diagram illustrating an example of mounting on an embedded device according to the first embodiment. FIG. 10 is a diagram for explaining control development according to the second embodiment. FIG. 11 is a diagram illustrating a design screen for control processing according to the second embodiment. FIG. 12 is a diagram for explaining GUI screen design according to the second embodiment. FIG. 13 is a diagram for explaining a superimposed display of a control process design diagram and a screen design diagram according to the second embodiment. FIG. 14 is a diagram illustrating a display state in which the control process design diagram and the screen design diagram according to the second embodiment are superimposed and one of them is translucent. FIG. 15 is a diagram for explaining a state when the layout of the superimposed display of the control process design diagram and the screen design diagram according to the second embodiment is changed. FIG. 16 is a flowchart of a process of associating a control process and a GUI component according to the second embodiment. FIG. 17 is a diagram for explaining replacement of the control process design diagram and the screen design diagram according to the second embodiment. FIG. 18 is a diagram for explaining association between a plurality of design drawings according to the second embodiment. FIG. 19 is a diagram illustrating a specific example of cooperation between a specification and a design document according to the second embodiment. FIG. 20 is a diagram illustrating a data relationship between the specification information and the design information according to the second embodiment. FIG. 21 is a diagram for explaining processing when a component is added according to the second embodiment. (Part 1) FIG. 22 is a diagram for explaining processing when a component is added according to the second embodiment. (Part 2) FIG. 23 is a diagram for explaining processing when a component is added according to the second embodiment. (Part 3) FIG. 24 is a diagram for explaining processing when a component is added according to the second embodiment. (Part 4) FIG. 25 is a diagram for explaining processing when a component is added according to the second embodiment. (Part 5) FIG. 26 is a diagram for explaining source code generation of processing (function) corresponding to the added component according to the second embodiment. FIG. 27 is a diagram for explaining processing at the time of changing specifications of a plurality of created documents or programs according to the second embodiment.

(Embodiment)
With reference to the accompanying drawings, illustrating how the development of embedded software according to the present invention, a preferred embodiment of the programming device and the embedded device in detail. The embedded software is software embedded in a specific-purpose embedded device whose application (operation) is limited, such as a remote controller, a digital camera, an IC recorder, an in-vehicle device, or a medical device.

(Embodiment 1: Configuration of data transmission / reception using a virtual memory interface)
FIG. 1 is a diagram for explaining the interface specifications of the embedded software according to the first embodiment. In the embodiment, connection between different programs A and B is performed using the virtual memory interface 101. This connection refers to transmission / reception of data exchanged between programs.

  FIG. 2 is a diagram of memory contents of the virtual memory interface according to the first embodiment. For each memory address, data (variables) exchanged between one program (for example, application) A and the other program (for example, OS) B is stored.

  Here, the virtual memory (interface) 101 is used for transmission / reception of the functions of the programs A and B and the function data between the programs A and B. The address written by each function and the address to be read are set in advance.

  In the embedded software, a specific function may be simply executed by order control or the like, and therefore data transmission / reception between the programs A and B is fixed. For example, the data acquired by the function A of the program (application) A by operating the embedded device is set to be written to the address “0000”.

  The function 1 of the program (OS) B is set to read data written at the address “0000” and execute a predetermined process. The function 1 of the program (OS) is set so that a return value of a predetermined process execution result is written to the address “0001”.

  The function A of the program (application) A is set so as to read the data of the address “0001” and execute a predetermined process. The other functions of programs A and B are also set to send and receive data using different addresses.

  FIG. 3 is a flowchart of the contents of data transmission / reception processing using the virtual memory interface according to the first embodiment. In the figure, step S301 shows the contents of the pre-processing performed when the embedded software is developed, and step S304 shows the contents of the execution process after the pre-processing (after incorporating the embedded software into the embedded device).

  As advance preparation of step S301, first, the variable area 1 to be transferred from the function A of the program A to the function 1 of the program B is set (step S302). Next, the variable area 2 of the return value from the function 1 of the program B to the function A of the program A is set (step S303).

  During the execution process after the advance preparation (step S304), the processes of steps S305 to S308 are performed. First, data is written in the variable area 1 by the function A of the program A (step S305). Next, data is read from the variable area 1 by the function 1 of the program B (step S306). Thereafter, the internal calculation is performed by the function 1 of the program B, and the return value of the calculation result is written in the variable area 2 (step S307). Data is read from the variable area 2 by the function A of the program A (step S308).

The process of FIG. 3 will be specifically described with reference to FIG.
a. The address “0000” of the virtual memory interface 101 is set as the variable area 1 to be transferred from the function A to the function 1.
b. The address “0001” of the virtual memory interface 101 is set as the variable area 2 of the return value from the function 1 to the function A.

At the time of operation processing after the above preparation, the programs A and B are as follows. ~ 4. Perform the process.
1. The function A writes data to the variable area 1 (address “0000”).
2. Function 1 reads data from variable area 1 (address “0000”).
3. Function 1 performs an internal calculation and writes the return value of the calculation result to variable area 2 (address “0001”).
4). The function A reads data from the variable area 2 (address “0001”).

  As described above, by setting the addresses to be written and read by the programs on the virtual memory interface 101 for the data exchanged between the programs A and B, the programs A and B can be controlled by the virtual memory interface. This data can be read and the program can be executed based on the data write to the corresponding address 101. Each of the programs A and B can establish cooperation between programs only by the memory read / write operation.

Here, each of the programs A and B may be configured (programmed) so as to execute processing when data is written to a preset address. For example, in the above example, 2.4. Can be programmed as follows.
2 '. The function 1 reads this data when data is written to the address “0000”.
4 '. The function A reads this data when the data is written to the address “0001”.

  FIG. 4 is a diagram illustrating a cooperation example of programs according to the first embodiment. The function A of the program A performs a process of writing the value 10 to the address 0 “0000” and a process of reading the value of the address 1 “0001”. The function 1 of the program B processes the value written at the address 0 “0000” (in the example shown, the value square process), and writes the processed value as a return value to the address 1 “0001”.

  According to the example of the program linkage shown in FIG. 4, the programs A and B can send / receive data to / from other programs and request data processing with only the WRITE function and the READ function. The programs A and B can be executed using only two functions of an address for READ and an address and value for WRITE.

  As described above, if the programs A and B only determine the rules for data transmission / reception via the virtual memory interface 101 (the address, the size of the data, and the contents of the processing) in advance, the programs A and B can interact with each other. Data exchange and transmission of processing requests can be realized very easily.

  In addition, programmers can implement (work) only reading and writing at a specific address in virtual memory, so knowledge and experience of functions such as API are not required, and as a result, programming is not necessary even for a non-skilled programmer. It will be possible to build an environment that can.

(Communication between programs for writing and reading using the virtual memory interface)
Next, in order to transmit to the partner program that the writing and reading in the above-mentioned program cooperation has been performed, the following 1. ~ 3. The method is used.
1. 1. Method for executing mutual program processing by data change by polling 2. A method of executing mutual program processing by event processing Method for executing mutual program processing via hardware

FIG. 5 is a diagram for explaining a method of executing mutual program processing by data change due to polling according to the first embodiment. 1. ~ 3. The program processing is executed according to the procedure.
1. Program (application) A rewrites data.
2. The program (application) B reads at polling (fixed intervals) whether or not data at a predetermined address (address “0000”) has been rewritten.
3. Then, the program (application) B reads the data (DATA1) when the data at the predetermined address (address “0000”) has been rewritten (DATA0 → DATA1), and executes predetermined processing.

FIG. 6 is a diagram for explaining a method of executing mutual program processing by event processing according to the first embodiment. 1. ~ 4. The program processing is executed according to the procedure.
1. At the time of initialization, the program (application) B registers to notify the OS 601 when a change occurs in data at a predetermined address “0000”.
2. The program (application) A rewrites the data at the address “0000” (DATA0 → DATA1).
3. The OS 601 notifies the program (application) B of the change of the address “0000”.
4). The program (application) B reads the data at the address “0000” and starts predetermined data processing.
As described above, in the event processing, all data is written and read via the OS 601.

FIG. 7 is a diagram for explaining a method for executing mutual program processing via the hardware according to the first embodiment. In the virtual memory interface 101, in addition to the data area, data read and functions activated by data write are registered. 1. ~ 3. The program processing is executed according to the procedure.
1. The program (application) A rewrites the data at the address “0000” (DATA0 → DATA1).
2. The CPU 701 calls the function (OnWrite0 ()) from the address “0000” written by the program (application) A and the data (DATA1).
3. The program (application) B reads and executes the rewritten data (DATA1).

  FIG. 8 is a block diagram of a hardware configuration example of a programming device used for embedded software development according to the first embodiment. In FIG. 8, the programming device 800 includes a control unit (CPU) 801, a read-only memory (ROM) 802, and a random access memory (RAM) 803. Further, a storage unit 804 such as a semiconductor memory or a disk drive, a display 808, a communication interface (I / F) 809, a keyboard 810, a mouse 811, a scanner 812, and a printer 813 may be provided. These CPU 801 to printer 813 are connected by a bus 814.

  The CPU 801 is an arithmetic processing device that performs overall control when the embedded software is created by the programming device 800. The ROM 802 is a non-volatile memory that stores programs necessary for creating embedded software. A RAM 803 is a volatile memory used as a work area when the CPU 801 executes arithmetic processing.

  A communication interface 809 controls an internal interface with the network 815 and controls input / output of data from an external device. Specifically, the communication interface 809 is connected to a local area network (LAN), a wide area network (WAN), the Internet, or the like serving as the network 815 through a communication line, and is connected to another device via the network 815. For the communication interface 809, for example, a modem or a LAN adapter can be employed.

  The display 808 includes various specifications and design documents for embedded software development, such as GUI (Graphical User Interface) screen design in operation specifications and program design document design screens, including cursors, icons, and tool boxes. This is a device for displaying data such as documents, images, and function information. As the display 808, for example, a Thin Film Transistor (TFT) liquid crystal display, a plasma display, an organic EL display, or the like can be adopted.

  Then, in the development of the programs (applications) A and B described above, the pre-processing S301 shown in FIG. 3 is performed using the programming device 800 shown in FIG. Thereafter, the execution processing step S304 shown in FIG. 3 may be executed in the embedded device.

(Implementation example)
FIG. 9 is a diagram illustrating an example of mounting on an embedded device according to the first embodiment. An embedded device whose use is limited stores programs (applications) A and B in a predetermined memory, and uses the virtual memory interface 101 provided by the OS 901 for data transmission / reception between the programs (applications) A and B. . Although not shown, the embedded device executes operation processing of these programs (applications) A and B, the OS 901, and the virtual memory interface 101.

  In the conventional interface, the program A is called by calling the API of the program B so that the programs are linked. In this case, it is necessary to read the API specification carefully, it must be associated with an appropriate function and factor, and programming by a skilled programmer is required.

  On the other hand, according to the first embodiment, data is transmitted / received between programs via the virtual memory interface. In the embedded software, each program is developed for each function module (for example, for each recording function and display function in the case of a recorder). According to the embodiment, at this time, it is not necessary to perform special programming such as using an API function for cooperation between programs, and it is possible to develop embedded software for which the user is responsible without knowledge of programming. become. In addition, embedded software development can be performed regardless of programming language or language (race) between programmers.

  Thereby, the program quality of embedded software development can be improved, and efficiency and cost can be reduced. Furthermore, embedded software development can be performed without a super programmer who supervises software development, and labor costs can be reduced.

  In addition, data transmission / reception between programs becomes clear at the prototype stage of embedded devices, and trial and error of programming (data transmission / reception) can be performed easily and easily, so that verification work at the prototype stage can be performed efficiently and smoothly.

(Embodiment 2: Cooperation between GUI development and control development)
In the second embodiment, cooperation of a plurality of documents in embedded software development will be described. This cooperation can also be performed using the programming device 800 shown in FIG.

  Conventionally, for example, the GUI screen design in the operation specification and the control processing (program description) in the program design are performed in separate steps, but in the second embodiment, these specifications (for example, GUI development) are performed. And design documents (for example, control development) are linked in an easy-to-understand manner.

  FIG. 10 is a diagram for explaining control development according to the second embodiment. As illustrated, in the embodiment, in the embedded software development, control is designed using a rule diagram without using conventional control processing (program description). The processing contents of the program description are expressed using a rule diagram 1000 composed of a combination of figures.

  In the rule diagram 1000, as shown in FIG. 10, a condition 1001 and an action 1002 are used as control processing components. Then, the action 1002 is executed when the condition 1001 is met. Connecting the condition 1001 in series represents a logical product (AND) condition, and connecting the condition 1001 in parallel represents a logical sum (OR) condition. At the time of control development, the rule diagram 1000 is created by systematically connecting these conditions 1001 and actions 1002 along the control processing procedure.

  FIG. 11 is a diagram illustrating a design screen for control processing according to the second embodiment. A control processing component list 1110 is displayed in the right column of the display screen of the control processing design diagram 1100 using the rule diagram 1000. In the control processing component list 1110, the conditions 1001, the action 1002, and the like shown in FIG.

  Then, an item required at the time of designing the control process is selected from the control process component list 1110 and arranged at an appropriate position on the rule diagram 1000 by an operation (drag and drop). Then, after the placement of the control processing components (condition 1001 and action 1002), the contents of the condition 1001 and action 1002 are set to determine the control operation. In the example of FIG. 11, in the rule diagram 1000, the condition 1001 and the action 1002 are set based on the operation of the embedded device (for example, the operation of the start button 1120 and the stop button 1130).

  FIG. 12 is a diagram for explaining GUI screen design according to the second embodiment. As illustrated, in the embodiment, in embedded software development, a GUI frequently used for an embedded device is designed using a screen design diagram 1200.

  On the screen design diagram 1200, the function of the operation screen of the embedded device is simply shown for convenience. For example, the start (START) button 1201 of the embedded device, the stop (STOP) button 1202, and other function buttons 1203 are displayed. Design and edit layouts.

  For example, a GUI component list 1210 is displayed in the right column of the display screen of the screen design drawing 1200. In the GUI component list 1210, a start (START) button 1201, a stop (STOP) button 1202, other function buttons 1203, and the like are arranged in advance. Then, a button necessary for designing the GUI screen is selected from the GUI component list 1210 and arranged at an appropriate position on the screen design diagram 1200 by an operation (drag and drop). Then, after the GUI component is arranged, the GUI screen is designed by setting the color and wording of the GUI component (for example, the word indicating the color and function for each function).

  When designing the control process, the display screen of the control process design diagram 1100 (rule diagram 1000) shown in FIG. 11 is used, and when the GUI screen is designed, the screen is switched to the display screen of the screen design diagram 1200 shown in FIG. At this time, on the control processing design diagram 1100 (rule diagram 1000) shown in FIG. 11, the start (START) button 1201 and the stop (STOP) button 1202 shown in FIG. 12 are arranged at the same position.

  FIG. 13 is a diagram for explaining a superimposed display of a control process design diagram and a screen design diagram according to the second embodiment. The screen design diagram 1200 shown in FIG. 12 is superimposed on the display screen of the control process design diagram 1100 shown in FIG. For example, the screen design drawing 1200 positioned above the overlay is displayed as a semi-transparent display so that the control processing design drawing 1100 positioned below can be visually recognized. However, the present invention is not limited to this, and the control process design diagram 1100 and the screen design diagram 1200 may be switched to each other or displayed in parallel on the same screen.

  Further, the screen display is not limited to the two control processing design diagrams 1100 and the screen design diagram 1200, and the display screens of three or more documents can be overlapped, switched, or displayed in parallel.

  In any case, the display (coordinates) position of the start (START) button 1201 on the control process design diagram 1100 and the screen design diagram 1200 is the same position. Similarly, the display (coordinates) position of the stop (STOP) button 1202 in the control processing design drawing 1100 and the screen design drawing 1200 is the same position. For the sake of convenience of explanation, only the start and stop of the embedded device have been described as the functions of the operation screen of the embedded device, but other functions that are the starting point of the control process and the GUI screen should be arranged in the same manner. Can do.

  FIG. 14 is a diagram illustrating a display state in which the control process design diagram and the screen design diagram according to the second embodiment are superimposed and one of them is translucent. In the example of FIG. 14, the control processing design diagram 1100 is displayed in a translucent manner (dotted line in the figure for convenience) with respect to the screen design diagram 1200. In this way, by superimposing and displaying the control process design diagram 1100 and the screen design diagram 1200, it becomes possible to intuitively understand the cooperation between the operation on the GUI screen and the control process. In the example of FIG. 14, it is possible to design the GUI screen design diagram 1200 while referring to the control process of the control process design diagram 1100.

  In contrast to FIG. 14, the screen design diagram 1200 is displayed semi-transparently with respect to the control process design diagram 1100, so that the control process of the control process design diagram 1100 can be performed with reference to the GUI screen design diagram 1200. It becomes possible to design.

  FIG. 15 is a diagram for explaining a state when the layout of the superimposed display of the control process design diagram and the screen design diagram according to the second embodiment is changed. 14 shows a state where the layout has been changed by moving the start (START) button 1201 and the stop (STOP) button 1202 to the right on the screen design diagram 1200 shown in FIG. Thus, when the button arrangement on the screen design drawing 1200 is changed, the control processing design drawing 1100 (rule diagram 1000) is also moved to the right in accordance with the change.

  In the example of FIG. 15, the conditions 1001 and the action 1002 starting from the start (START) button 1201 and the conditions 1001 and the action 1002 starting from the stop (STOP) button 1202 do not overlap each other. The layout is changed. When the layout is changed, the rule diagram 1000 can be changed to a flexible form by changing the connection positions of the lines connecting the buttons, conditions, and actions.

  FIG. 16 is a flowchart of a process of associating a control process and a GUI component according to the second embodiment. The control processing shown in the control processing design diagram 1100 and the processing for associating the GUI components shown in the screen design diagram 1200 will be described. This processing is executed by the programming device 800.

  First, the programming device 800 superimposes and displays the screen of the control process design diagram 1100 and the GUI screen design diagram 1200 (step S1601). Thereafter, the corresponding control processing component (condition 1001, action 1002) in the control processing design diagram 1100 and the GUI components (start (START) button 1201, stop (STOP) button 1202) in the screen design diagram 1200 are selected. (Step S1602).

  The programming device 800 stores the screen of the superimposed control processing design diagram 1100, information of the GUI screen design diagram 1200 (including the coordinate position of each component), and information on the associated control processing component and GUI component. The data can be displayed on the display by being read from the storage unit 804 and can be edited later.

  The association process is not limited to the above, and a GUI component in the screen design diagram 1200 may be selected, a control processing component in the control process design diagram 1100 corresponding to this GUI component may be selected, and associated with each other.

  FIG. 17 is a diagram for explaining replacement of the control process design diagram and the screen design diagram according to the second embodiment. FIG. 17 shows a state in which two GUI screen design drawings 1200 a and 1200 b are associated with one control processing design diagram 1100. In this figure, two buttons 1201a and 1202a in one screen design diagram 1200a are examples in which characters are displayed in Japanese, and two buttons 1201b and 1202b in the other screen design diagram 1200b are examples in which characters are displayed in English. .

  As described above, when the screen design drawings 1200a and 1200b are different in character notation, the components for control processing in the control processing design diagram 1100 (in the example shown, only the actions 1002a and 1002b are described in common) are used in common. be able to. In such a case, a plurality of screen design diagrams 1200a and 1200b can be prepared for each language for one control process design diagram 1100. For example, “button A” (1201a) in Japanese of the screen design diagram 1200a and “Button A” (1201b) in English of the screen design diagram 1200b are both in the action 1002a of the common control processing design diagram 1100. Connected.

  The programming device 800 associates the screen design drawings 1200a and 1200b of these two GUIs with one control processing design diagram 1100, and mounts the information on the associated states in the embedded device. In the embedded device, when Japanese notation is selected by a user operation, the screen design diagram 1200a may be validated and the screen design diagram 1200b may be invalidated as illustrated. When English notation is selected, the screen design diagram 1200b is validated and the screen design diagram 1200a is invalidated.

  According to the above configuration, one control process can be set by switching (replacing) a plurality of GUI screens. In the above example, GUI language switching has been described as an example. However, the present invention is not limited to this, and the display of various GUI screens according to the size of GUI components, the size of characters (fonts), the types of characters, and user preferences, The control process can be made common and the GUI screen can be switched.

  Thereby, it is possible to flexibly cope with specification changes, and for example, it is possible to add or change different GUIs later. In addition to the above example, one GUI screen can be set by switching to a plurality of control processes.

  FIG. 18 is a diagram for explaining association between a plurality of design drawings according to the second embodiment. In FIG. 18, in addition to the association between the screen design diagram 1200 and the control processing design diagram 1100 described above, an I / O design drawing and an event (Event) design drawing are also added to associate each other. It is.

  The association between the GUI screen design diagram 1200 and the control process design diagram 1100 of the control process is as described above. In addition to this, a different display screen may be used for each input having different properties such as the physical input / output I / O design diagram 1801 and the event design diagram 1802 of the inter-task signal. In the illustrated example, each I / O condition in the I / O design drawing 1801 and each event in the Event design drawing 1802 are all connected to an action 1002 in the control processing design drawing 1100.

(Specific examples of cooperation between specifications and design documents)
FIG. 19 is a diagram illustrating a specific example of cooperation between a specification and a design document according to the second embodiment. In FIG. 19, the screen design diagram 1200 described above is edited by editing the specification editing screen 1901 (display color editing of buttons on the screen), and the control processing design diagram 1100 described above is edited by the design document editing screen 1911. An example is shown.

  A screen setting diagram 1902 and a display / operation list diagram 1903 are arranged on the specification document edit screen 1901, and a display message list 1904 and a screen changeover switch 1905 are provided below the screen setting diagram 1902.

  On the screen setting diagram 1902, desired components (blue button 1906 and red button 1907 in the illustrated example) are set and arranged at desired positions. The display / operation list 1903 describes operation specifications for the arranged components (blue button 1906, red button 1907). For example, as shown in the drawing, the operation 1909 “display blue” when the “blue button is pressed” is described as the condition 1908. The same applies to red.

  A screen setting diagram 1912 and a display / operation list diagram 1913 are arranged on the design document editing screen 1911, and a display message list 1914 and a screen changeover switch 1915 are provided below the screen setting diagram 1912.

  Parts arranged in the screen setting diagram 1912 (blue button “Button_Blue” 1906, red button “Button_Red” 1907) are displayed at the same coordinate position. Display / operation list FIG. 1913 describes a display color as an operation 1917 for the condition (button operation) of the arranged components (blue button 1906, red button 1907). For example, when the “blue button 1906” is operated, a display color “Button_BlueDisplay” and a function for the program are described using a name corresponding to the program implementation.

  The specification editing screen 1901 and the design document editing screen 1911 can be switched between each other by operating the screen switching switches 1905 and 1915. Further, not limited to switching, as described above, they can be displayed on the same screen.

  The contents edited on the specification edit screen 1901 can be converted into an instruction manual (manual) 1921 and a test specification 1922. In addition, the editing contents on the design document editing screen 1911 can be converted into a debug specification 1923. Further, the source code of the program 1924 can be generated based on the editing contents of the design document editing screen 1911.

  FIG. 20 is a diagram illustrating a data relationship between the specification information and the design information according to the second embodiment. The contents edited by the specification editing screen 1901 and the design document editing screen 1911 are sequentially stored in the storage unit 804 of the programming device 800.

  The programming device 800 lists the list of conditions 1908 in the display / operation list diagram 1903 and the operation 1909 corresponding to each condition 1908 as the specification information 2001 by editing the specification edit screen 1901. The association with the operation 1909 is set. Also, for the design document information 2011 by editing the design document editing screen 1911, the operations 1917 corresponding to the conditions 1916 are listed, and the correspondence between the conditions 1916 and the operations 1917 is set.

  The specification information 2001 is stored in the specification database (DB) 2002, and the design information 2011 is stored in the design database (DB) 2012. In addition to the specification DB 2002 and the design data DB 2012, the various specifications shown in FIG. 19 are converted into a database and stored in the storage unit 804 of the programming device 800.

  The programming device 800 also associates the specification information 2001 and the design information 2011. That is, each condition 1908 of the specification document information 2001 is associated with each condition 1916 of the design document information 2011. Further, each operation 1909 of the specification document information 2001 is associated with each condition 1917 of the design document information 2011.

(Processing when adding a part: Example of adding a button)
Next, processing contents when adding a component (function) will be described using an example in which a button is newly added and a display color is set. Processing contents performed by the programming device 800 will be described.

  FIGS. 21 to 25 are diagrams for explaining processing when a component is added according to the second embodiment. An example in which another component (yellow button 2101) is newly added in addition to the components (blue button 1906, red button 1907) shown in FIG. 19 will be described.

  As shown in FIG. 21, when the yellow button 2101 is added, first, (1) the component (yellow button) 2101 is arranged at a predetermined position on the screen setting diagram 1902 of the specification edit screen 1901. Corresponding to this arrangement, the programming device 800 automatically arranges the component (yellow button) 2101 at the same position on the screen setting diagram 1912 of the design document edit screen 1911.

  (2) On the specification editing screen 1901, the programming device 800 corresponds to the yellow button 2101 arranged on the screen setting diagram 1902, and the specification for the yellow button 2101 arranged in the display / operation list diagram 1903. An explanation (operation) area 2102 is automatically created. At this time, the content of the specification explanation (operation) area 2102 is left blank.

  (3) Next, the programming device 800 displays the display / operation list 1913 on the design document edit screen 1911 corresponding to the specification explanation (operation) area 2102 created in the display / operation list diagram 1903 on the specification edit screen 1901. A specification explanation (operation) area 2103 is automatically created. At this time, the content of the specification explanation (operation) area 2103 is blank.

  Thereafter, as shown in FIG. 22, specifications are described in a specification explanation (operation) area 2102 of the specification document editing screen 1901 and a specification explanation (operation) area 2103 of the design document editing screen 1911, respectively. More specifically, (4) specification description (operation) area 2102 describes the operation “display yellow” when the condition “yellow button is pressed” as the specification of the yellow button 2101. Also, (5) Specification Description (Operation) area 2103 describes “Button_YellowDisplay” as a processing function. At this time, if there is a specification / function database (DB) 2201 in the programming device 800, processing (function) for the yellow button 2101 can be automatically set by referring to this. Finally, (6) the name “Button_Yellow” of the yellow button is described in the part (yellow button) 2101 arranged on the screen setting diagram 1912 of the design document editing screen 1911.

  In association with the processing shown in FIG. 21, the programming device 800 associates and stores the specification information and the design information as shown in FIG. The contents of additional information for FIG. 20 will be described with reference to FIG. (4) In the specification information 2001, “Yellow button pressed” is added to the condition list 1908 as the condition 2301, and “display yellow” is added to the action list 1909 corresponding to the condition list 1908 as the action 2302. .

  Also, (5) “Button_YellowDisplay” is added to the operation list 1917 as the process (function) 2303 in the design document information 2011. Finally, (6) “Button_Yellow :: OnClick” indicating the operation of the yellow button is added as a condition 2304 to the condition list 1916.

  After the processing of FIG. 22, as shown in FIG. 24, (7) In the design document editing screen 1911, the component (yellow button) 2101 and the corresponding processing (function) 2103 are used using the mouse of the programming device 800 or the like. Are connected to each other (line 2401 in the figure).

  24, for the design document information 2011 shown in FIG. 25, the programming device 800 (8) condition 1916 “Button_Yellow :: OnClick” and processing (function) 1917 “Button_YellowDisplay” corresponding to the condition 1916. ”(Line 2501 in the figure). Further, the condition 1908 “Yellow button pressed” of the specification document information 2001 is associated with the condition 1916 “Button_Yellow :: OnClick” of the design document information 2011 (line 2502 in the figure).

(Processing when adding parts: Generating source code)
FIG. 26 is a diagram for explaining source code generation of processing (function) corresponding to the added component according to the second embodiment. After the processing at the time of component addition shown in FIGS. 21 to 25, the programming device 800 additionally generates (9) source code of processing (function) corresponding to the added component (yellow button) 2101, and other buttons. A program 1924 composed of source code including the above process is generated. At this time, the processing 2601 “SetPanel (“ Yellow ”);” is manually written in the source code “Button_YellowDisplay” of the program 1924 (10).

  FIG. 27 is a diagram for explaining processing at the time of changing specifications of a plurality of created documents or programs according to the second embodiment. The programming device 800 associates a specification editing screen 1901, a design document editing screen 1911, and a program 1924 with each other. Therefore, when any of the specification editing screen 1901, the design document editing screen 1911, and the program 1924 is changed to any screen, any code, or any part, the programming device 800 displays other screens, The change is automatically reflected in the part corresponding to the code.

  In general, software development involves: (1) Specification creation (test specification creation, manual creation), (2) Software design creation, (3) Source code creation, (4) Compilation in actual machine environment, (5) It is performed in the order of actual machine operation. The development involves specification designers, software designers, programmers, manual developers, and test designers.

  The programming device 800 according to the second embodiment centrally manages each document necessary for development, and when any document correction is performed, the corresponding part of another related document is corrected. As a result, a plurality of developers involved in software development can always develop while grasping the development situation including correction of other documents, and software development can be performed smoothly and efficiently.

  In the above description, the buttons are arranged as components, and the operation conditions and operation setting examples are described. However, not only buttons but also various components, for example, time, alarm, timer, etc. are set as display screens in the same manner. can do. Further, not only the setting of screen design (GUI) components but also a plurality of documents related to the setting of UI can be similarly associated.

  According to the second embodiment, in software development, GUI development and control development can be linked, and a document created in one development can be reflected (created) in the other development. As a result, it is possible to reduce the time and effort required to create individual documents for GUI development and control development, and development is possible even if the development procedures described above are different (changed). This makes it possible to reduce software development man-hours and costs.

  The second embodiment is suitable for linking documents of each development process in embedded software development of an embedded device for a specific application. As a result, it is possible to omit processing related to document creation that has been performed in GUI development and control development, and to perform embedded software development smoothly and efficiently.

  As described above, the present invention is useful for embedded software and the development thereof, and particularly useful for the embedded software incorporated in a specific-use embedded device whose use is limited and the development thereof.

DESCRIPTION OF SYMBOLS 101 Virtual memory interface 800 Programming device 804 Memory | storage part 808 Display 809 Communication interface 810 Keyboard 811 Mouse 812 Scanner 813 Printer 814 Bus 815 Network 1001 Condition 1002 Action 1901 Specification edit screen 1911 Design document edit screen A, B Program

Claims (5)

Depending on the processor of the programming device,
For data transmission / reception of a first program and a second program of a plurality of programs by function module of the embedded software executed by the embedded device ,
A first address of a data area that the first program passes to the second program;
A second address of a data area that the second program passes to the first program;
Is set in the virtual memory interface provided by the OS of the embedded device ,
The functions of the first program and the second program that are activated by writing and reading data with respect to an address are set in advance in the virtual memory area of the virtual memory interface.
Process
The CPU of the embedded device is set by the programming device,
By the first program, write the data to be passed to the second program to the first address of the virtual memory interface,
By the second program, it reads the data written to the first address, write data of the return value of performing predetermined processing on the second address,
By the first program, for reading the data of the written return value to the second address,
CPU before Symbol embedded devices, the function calls of the second program corresponding to the written address and data by the first program,
The written data is read by the second program.
Development process of embedded software and performs processing. The CPU of the embedded device is
The writing of the data to the first address of the virtual memory interface by the execution process of the second program is monitored at regular intervals, and the data written to the first address is read according to the data writing. ,
Developing embedded software according to claim 1, characterized in that. The OS of the embedded device notifies the second program of writing of the data to the first address of the virtual memory interface,
The second program reads the data written to the first address in response to a notification from the OS.
Developing embedded software according to claim 1, characterized in that. In a programming device that develops embedded software for embedded devices ,
For data transmission / reception of a first program and a second program of a plurality of programs for each functional module executed by the embedded device ,
A first address of a data area that the first program passes to the second program;
A second address of a data area that the second program passes to the first program;
Is set in the virtual memory interface provided by the OS of the embedded device ,
The functions of the first program and the second program that are activated by writing and reading data with respect to an address are set in advance in the virtual memory area of the virtual memory interface.
A programming device comprising a control unit for performing processing . A first address of a data area that the first program passes to the second program for sending and receiving data of the first program and the second program of the plurality of programs for each function module of the embedded software, and the second program is the first program A virtual memory interface provided by the OS, in which a second address of a data area to be passed to one program is preset;
Based on the preset settings of the functions of the first program and the second program that are started by writing and reading data to and from the virtual memory area of the virtual memory interface in advance,
The first program writes data to be passed to the second program to the first address of the virtual memory interface,
The second program reads the data written to the first address, writes the data of the return value obtained by performing a predetermined process to the second address,
The first program reads the data of the return value written to the second address,
Calling a function of the second program corresponding to the address and data written by the first program;
The written data is read by the second program.
An embedded device comprising a control unit for processing .

Images