JP2007128456A - Program management device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a program management device capable of surely and easily managing test work for a program component including a change point. <P>SOLUTION: This program management device is provided with a program component database 70 and a component relationship diagram editor 64. In the program component database 70, a plurality of versatile resource program components 68, by which an apparatus control program is constructed, with described macros and a test scenario, in which an input condition to a specific application program component 73 generated based on the resource program components and an expectation output are written in time series, are stored in association with each other. The component relationship diagram editor 64 displays a component relationship diagram showing a connection relationship between the resource program components on a display device, makes the resource program component as a treatment target and its treatment content to be selected, and actuates a component editor 65 or a unit test tool 71 based on the selected treatment content. A comparison result by the unit test tool is reflected to a display mode of the resource program component on the component relationship diagram. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a program management apparatus capable of editing and testing a program part constituting a device control program.

  Inspection devices and equipment devices installed in factories are controlled by an industrial control device executing an equipment control program. A specific example of the industrial control device is a programmable controller. Programmable controller users, such as factory equipment personnel and production engineering personnel, create a ladder program in advance using a programming tool in order to cause the programmable controller to execute arbitrary control. Then, the ladder program is stored in the programmable controller. The programmable controller executes a ladder program cyclically and arbitrarily controls the inspection apparatus and the equipment apparatus. Recently, even if part of the control contents of the programmable controller is different, edit or modify part of the existing ladder program as needed, that is, reuse the ladder program to make programming work more efficient. It is planned to become. At that time, the program parts management tool also attempts to create a database of programs to be reused.

  Ladder program componentization and reuse are generally implemented using a "function block" mechanism defined in the IEC61131 standard. The function block realizes encapsulation of the ladder program and variables, and the ladder program can be reused as a part. The variable is, for example, an input / output contact that is a control target of the programmable controller. In addition, when a part of the ladder program is edited or modified as necessary, the program that is displayed in graphic form is replaced by replacing the complex processing that appears in multiple places on the program with simple macro operation parts. It is also known that simplification of partial editing and partial change is performed (see Patent Document 1).

  In recent years, a method called “product line software engineering” (hereinafter abbreviated as PLSE) has been proposed to analyze the commonality and differences in product lineups and to create effective software assets. . On the other hand, in the field of equipment control systems where ladder programs are used, a large number of systems that are largely identical but partially different are being developed so that the product lineup can be enhanced to meet the needs of users. There are many. Therefore, the effectiveness of applying PLSE is also expected for the design and development of ladder programs for controlling such systems.

  However, the function block method has the following problems in making program parts based on such analysis. That is, the programmable controller operates by cyclically scanning all the circuits of the ladder program. Therefore, an increase in the scale of the program directly leads to a decrease in the execution time performance of one scan in the programmable controller, which in turn leads to a delay in the control response time of the equipment device to be controlled. Therefore, from the viewpoint of execution performance, it is desirable that the ladder program component does not include unnecessary circuits depending on the application to be controlled.

On the other hand, to create a versatile program part that can be reused in multiple applications, the internal structure of the program part and the behavior of the control target have some variation and can be set as options during programming. It is necessary to build a program so that the behavior can be changed a little. For example, when considering the fire detection algorithm program parts, even if the algorithm itself is the same, such as the number and type of fire detection sensors and whether or not there is a self-diagnosis function, there are multiple variations and options depending on the specific application used. Is often included. In such an option selection, a program part having versatility can be mounted by describing the program part as an input value. However, in this case, a ladder circuit that is unnecessary for realizing a certain system exists in the component (function block), and the execution performance of the program is lowered. For this reason, it is difficult to construct a versatile program component in a field where execution performance is severely restricted.
JP-A-6-230804

  In the PLSE method, in order to create a strategic reusable part, it is proposed to incorporate an anticipated change point in the program part. Therefore, the present inventors define a variable point (change point) of a program part as one of the means for realizing it, and incorporate a macro description for modifying a part of the program in a ladder program in advance, A method for generating a part of a program that has been modified by changing the set and executing macro processing has been proposed (Japanese Patent Application No. 2005-288858). As a result, the final ladder program generated by executing the macro process is made up of ladder circuits that are necessary and sufficient for the application to be applied, eliminating unnecessary ladder circuits, thereby enabling the scale of the program to be increased. Thus, it is possible to reduce the size and improve the execution time performance.

  However, to ensure the quality of program parts including change points, it is necessary to test the change points for each deformed part. If a defect is found as a result of the test, the program needs to be corrected, and the correction may affect a part that has already been tested and passed. In this way, program correction, test execution, and test result management become complicated, and unexpected malfunctions and test omissions may occur due to erroneous operations or misunderstandings.

  It is an object of the present invention to provide a program management apparatus capable of reliably and easily managing a test operation of a program part including a change point.

  In order to achieve the above object, a program management apparatus according to the present invention provides a plurality of versatile asset program parts for configuring a device control program, and a specific application generated based on the asset program parts. Program component storage means for associating and storing test scenarios in which input conditions and expected outputs to program components are described in time series, and a related diagram showing the connection relationship of the asset program components on the display device, and processing target A selection means for selecting the asset program parts and processing contents, an editing means for editing the asset program parts, and a simulator in which the specific application program parts are downloaded, according to the test scenario, and giving input conditions, Execution result of the simulator and the expectation Comprising a test means for comparing the force, the. The asset program part is a program part that includes the change point as a macro description when there is a change point that is expected in advance, and is for the specific application corresponding to the asset program part that includes the macro description. The program parts are generated by executing a macro process, and the display mode of the asset program parts on the related diagram is configured to reflect the comparison result by the test means.

  The program component storage means corresponds to the program component database 70 in the embodiment. The related diagram corresponds to the component related diagram in the embodiment. The processing contents correspond to the editing process and the unit test in the embodiment. The selection means corresponds to the component relation diagram editor 64 in the embodiment. The editing means corresponds to the component editor 65 in the embodiment. The test means corresponds to the unit test tool 71 in the embodiment.

  By selecting the asset program part on the related diagram and selecting the processing contents by the selecting means, the editing means or the testing means can be activated according to the selected processing contents. As a result, after the program is corrected, the part can be tested intuitively.

  Also, asset program parts and test scenarios are stored in association with each other, tests are executed based on the specific application program parts generated from the selected asset program and the corresponding test scenarios, and the test results are managed. Thus, it is possible to prevent a test scenario selection error for each specific application program component.

  Since the test results are reflected in the display form of the asset program parts displayed on the related diagram, the test results of each asset program part can be visually confirmed, and the test has not been completed (passed) The program can be easily found, and administrative careless mistakes such as check omissions can be prevented.

  It is determined whether or not there is a child asset program part in the asset program part selected by the selection means, and when the child asset program part exists, the asset program part and the child asset program A program synthesizing unit that synthesizes the component and generates one program may be provided, and the editing unit may perform an editing process on the program synthesized by the program synthesizing unit.

  In this case, display of the contents of the program is permitted for the child asset program parts, but it is preferable to include prohibition means for prohibiting editing by the editing means. In the embodiment, the prohibiting means is realized by setting a read-only attribute flag in the asset program part and turning the flag ON / OFF.

  It is determined whether or not there is a child asset program part in the asset program part selected by the selection means, and when the child asset program part is present, the specific program corresponding to the asset program part is determined. The specific program that is downloaded and executed by the simulator has program synthesis means for generating one program by synthesizing the application program component and the specific application program component corresponding to the child asset program component The application program component can be a program generated by the program synthesizing means.

  Reflecting the comparison result by the test means can make it possible to distinguish between those that have passed the test scenario and those that have not passed. In addition, “not passing” means that there is an untested state, but there is a case where the result of testing is unsuccessful. It is sufficient that at least one that has passed and one that has not passed can be identified. However, for those that have not passed, it is preferable to further identify the failure and the untested one.

  It may be provided with means for determining whether or not the editing program has edited the asset program part in the display mode that has passed, and changing the display mode to a state that has not passed if the editing process has been performed. In the embodiment, such means is realized by a component relation diagram editor. When the editing process is executed on the passed asset program part, the contents of the program are changed, so the meaning of the previous pass is lost. Therefore, in the present invention, by automatically changing the display mode to a curing that does not pass, it is possible to ensure that the edited program part is tested without overlooking that it is necessary to test again. Can do.

  If all the test scenarios prepared for an asset program part pass, the asset program part can be passed. Saying that all test scenarios have passed means that the program has been successfully completed. The test of the present invention does not necessarily pass when all of the prepared test scenarios have passed. For example, when the test scenario is to be selected by the user, the test scenario selected and executed is passed ( It is also possible to determine that the test has passed if not rejected. In such a case, it is better to change the display form of the test scenario that has passed all the test scenarios and the test scenario that has passed all of the selected test scenarios (although it may not be different).

  The asset program component may be a ladder program, and the change point may be described in a macro processing language for the purpose of rearranging the contacts and circuits of the ladder program.

  In the present invention, it is possible to reliably and easily manage the test operation of the program part including the change point.

  Prior to the description of the embodiment of the present invention, a presumed change point is incorporated into a ladder program as a macro description, the parameter set given according to the application is changed, and macro processing is executed. A technique for generating application program parts will be described.

  First, the reuse range is limited to similar common application groups (product lines). In other words, the reuse of program parts was considered only within the scope of a specific product line (product series). For example, it is limited to one product domain such as a mobile phone, a CD player, and a semiconductor manufacturing apparatus, and the reuse range is a range that assumes the limited product lineup and version upgrade. This is because, in the development of a conventional user program, for example, when developing a ladder program that controls operation / control of a certain product or a production line for producing the product, attention is paid only to the product, Had created a dedicated ladder program for the production line. On the other hand, when creating a versatile program part that can be reused in a plurality of applications, in order to create a strategic reuse part by the PLSE method, a change point that is expected in advance is incorporated into the part. In this case, rather than unnecessarily expanding the range of multiple applications to be assumed, it is more appropriate to consider reusing program parts only within the range of a specific product line (product series) as described above. Parts can be created.

  Specifically, the commonality and the difference are analyzed in the application group (product line) of the target product, and the program part is designed so that the common part and the difference part are not mixed in one program part. FIG. 1 is a diagram for explaining an example in which commonality and difference between products are divided. FIG. 6A shows an example in which a program for the product is created by analyzing only the above-described conventional product A (application) to be developed. Here, for convenience, it is assumed that a ladder program is constructed by four modules (function blocks). In this state, a product of the same series (variation: assortment) as the product may exist, or a version upgrade based on the product may be performed. In such a case, the products A1, A2,... Of the variations and the upgraded products A ′, A ″,... Are often in common with the original product A and are for the products A1, A ′, etc. In many cases, the ladder program of can be manufactured by editing and changing a part of the ladder program of the original product A. However, normally, when developing a ladder program for product A, When developing a ladder program for the next upgraded product A ′ or the product A1 of a variation of the product A in order to create only the product A, for example, at the change point X in FIG. As shown, there are many changes.

  This makes it difficult to know where to change to create the next product. Moreover, those changed locations X are incorporated in the modules A to D, and some of them exist across a plurality of modules, and it is difficult to deal with by changing only the changed locations. Therefore, even when there are many common parts and it can be dealt with by partial changes, it may actually be necessary to create a ladder program that matches the product again.

  Therefore, as shown in the figure (b), by analyzing not only the target product but also the future product version in addition to the product lineup, the commonality and the difference are analyzed in advance. As shown in FIG. 3C, it is possible to configure a module E in which only different portions are collected in the variation of the target product. Then, by designing the parts by clearly dividing the common part and the difference part in this way, when creating a different product variation or the like, it can be easily replaced with another module F corresponding to the difference part. Product variations can be created.

  FIG. 2 shows an inspection apparatus as one application. As surrounded by a dotted line in the figure, the inspection apparatus is roughly divided into six parts depending on the function and processing contents.

  That is, this inspection apparatus includes a supply unit 1, a load arm 3, an index table 4, an inspection head 5, an unload arm 6, and a discharge unit 7. The supply unit 1 includes a hopper 1a that stores the workpiece W to be inspected, an elevator 1b that moves up the workpiece W that is unloaded one by one from below the hopper 1a, and a workpiece W that is moved up by the elevator 1b. And a downwardly inclined shooter 1c to be carried out. The work W moves so as to slide down the shooter 1 c and reaches the tip of the supply unit 1. The supply unit 1 is an elevator supply device including an elevator 1b.

  The load arm 3 is a robot that holds the workpiece W positioned at the tip of the supply unit 1 and turns and places the workpiece W at a predetermined position on the index table 4. That is, the robot arm 3 is a form of robot transportation that carries a work into the index table 4. In addition, there are various alternatives such as a robot arm that can move in a three-dimensional space.

  As the index table 4 rotates, the workpiece W moves to the inspection position, and the inspection head 5 descends to a predetermined position for inspection. The index table 4 further rotates and moves the workpiece W to the take-out position. That is, the index table 4 is controlled to rotate and stop every 90 degrees. As a result, the workpiece W supplied by the load arm 3 rotates 90 degrees and moves to the inspection position, and then moves further 90 degrees and moves to the discharge position. In other words, the index table 4 operates so as to be positioned at four positions.

  The means for moving the workpiece to a desired position such as an inspection position or a discharge position is not limited to the index table 4 and includes, for example, a belt conveyor and various other means. When a belt conveyor is used, a sensor for detecting a workpiece is provided, and positioning can be performed by stopping the belt conveyor when the workpiece comes to the sensor position. Therefore, it can be positioned at any position by adjusting the installation position of the sensor.

  The inspection device 5 can perform pass / fail determination by taking shape and color information into account by using, for example, a color sensor. Thereby, more accurate determination can be performed. Further, the present invention is not limited to this, and it is also possible to perform a pass / fail judgment simply and in a short time using an image sensor that recognizes the shape.

  The workpiece W moved to the discharge position is gripped by the unload arm 16 and taken out from the index table 14 and sent to the discharge unit 17. Then, the discharge unit 17 sorts and discharges non-defective / defective products according to the inspection result.

  As described above, the application (inspection apparatus) shown in FIG. 2 can construct variations with different specifications. FIG. 3 shows, in a tabular form, an example of an application that has the same inspection function as the above-described inspection apparatus but includes variations with different specifications in some characteristics. The inspection apparatus A in the figure is an example of the inspection apparatus described with reference to FIG. 2, and the inspection apparatus B is a variation in which the characteristics of the inspection apparatus A are partially changed. Comparing the characteristics of the inspection apparatus A and the inspection apparatus B shown in the same drawing, both robot transportation is adopted for loading and unloading workpieces, but there are differences in other characteristics. For example, in the supply section, the inspection apparatus A employs elevator supply, but the inspection apparatus B does not employ (no supply section). Similarly, in order to position the workpiece to be inspected, the inspection apparatus A uses an index table, but the inspection apparatus B employs a belt conveyor. Similarly, the inspection apparatus A performs positioning by four positions for the workpiece stop position, but the inspection apparatus B employs positioning by a sensor. And when inspecting, although the inspection apparatus A employs a color sensor, the inspection apparatus B uses an image sensor. Further, regarding the discharge of the workpiece after the inspection, the inspection apparatus A separates the non-defective product from the defective product by the robot, and the inspection device B adopts a method of pushing out only the defective product.

  Component related diagrams in which the inspection apparatus A and the inspection apparatus B are divided into a common part and a different part according to characteristics are shown in FIGS. Unlike the characteristics selected by the user, the “component relation diagram” is a part diagram created from the viewpoint of what and how to create, and corresponds to a software design class diagram. Then, referring to the analysis result, the parts are designed so that the common characteristics and the difference characteristics are not mixed in one part.

  FIG. 4 shows an overall view of the components. As shown in the figure, the inspection apparatus 20 is divided into a work carry-in part 21, a positioning part 22, an inspection part 23, and a work carry-out part 24. The workpiece carry-in unit 21 further includes a supply unit 21a and a load arm 21b. The positioning unit 22 includes an index table 22a and a belt conveyor 22b, the inspection unit 23 includes an inspection method 25, and the work unloading unit 24 includes an unload arm 24a and an unloading unit 24b. In terms of the relationship with the six parts in the actual apparatus (application), the work carry-in part 21 is constituted by the supply part 1 and the load arm 3, and the work carry-out part 24 is constituted by the unload arm 6 and the discharge part 7. Is configured.

  FIG. 5 corresponds to a part of the component relation diagram of FIG. 4, and shows the commonality and difference between the inspection apparatus A and the inspection apparatus B in the work carry-in unit 21. As shown in the figure, the inspection apparatus A is provided with a supply part (elevator supply) 21a and a load arm 21b as a work carry-in part 21, whereas the inspection apparatus B does not have a supply part 21a but a load arm. Only 21b is provided. That is, in these inspection apparatuses, the supply part 21a is a different part, and the load arm 21b is a common part. And the supply part 21a used as the difference part in a product variation in this way is cut out as an optional component.

  6 corresponds to a part of the component relation diagram of FIG. 4, and shows the commonality and difference between the inspection apparatus A and the inspection apparatus B in the positioning unit 22. As shown in the figure, the inspection apparatus A employs an index table 22a as the positioning portion 22, whereas the inspection apparatus B employs a belt conveyor 22b. That is, in these inspection apparatuses, either the index table 22a or the belt conveyor 22b is selected. In such a case, the index table 22a and the belt conveyor 22b are cut out as substitute parts (substitute components).

At this time, as a macro example to extract the necessary circuit in the ladder program in line units,
! $ IF (condition) [
true statements
! ] [
false statements
! ]
It becomes. Here, the condition is described in condition. If you are conditional on whether a characteristic is selected,
; $ Feature = true
Or
; $ Feature = false
Is described. At this time, a specific characteristic name is designated as a feature. Truestatements and false statements contain the circuit in the range you want to extract, and are enclosed in [] written in the line comment.

  Examples using such macros are shown in FIGS. FIG. 7 shows a function block of the workpiece carry-in unit 21 described above, and the handling of options is shown. As shown in the figure, “Elevator supply” is described as a condition and indicates that it is selected as an option.

  FIG. 8 shows a function block of the positioning unit 22 and shows an alternative treatment. As shown in the figure, an index table and a belt conveyor are described as alternatives. In this way, the difference that occurs in the components for each application is dealt with by deformation of the components. In addition, although the elevator supply in the workpiece carry-in part 21 and the index table and the belt conveyor in the positioning part 22 have been described here, it is needless to say that other differences can be dealt with similarly.

  9 and 10 show examples of characteristic models. The characteristic model is a model that represents the product lineup by characteristics. Here, the “characteristic” is a concept that becomes a reference for the user to select a product, such as function, performance, and design. In addition, the characteristic model is a characteristic model obtained by analyzing devices by paying attention to commonality and difference.

  As shown in these drawings, the inspection apparatus 30 is divided into components of a supply 31, a workpiece carry-in 32, a positioning 33, an inspection 34, a workpiece carry-out 35, and a discharge 36 according to the characteristics. The supply 31 is provided with an elevator supply as an optional component. Here, a circle 37a provided in the elevator supply indicates that this characteristic is set to be selectable as an optional component. On the other hand, the robot transports 38 and 40 provided in the workpiece carry-in 32 and the workpiece carry-out 35 are not optional characteristics, and thus are not displayed as a circle 37a in the elevator supply 37.

  Further, the positioning 33 is provided with a stop position 39, and the stop position is further provided with a 4-position 39a and a sensor positioning 39b as alternative components in view of its characteristics. Similarly, a color sensor 34a and an image sensor 34b are set for the inspection 34, and a defective product push-out 36a and a robot sorting 36b are set for the discharge 36, respectively.

  Further, when this characteristic model is compared with the component relation diagram shown in FIG. 4, the supply 31 and the workpiece carry-in 32 of the characteristic model diagram correspond to the workpiece carry-in portion 21 of the component relation diagram, and the workpiece of the characteristic model diagram. The carry-out 35 and the discharge 36 correspond to the work carry-out unit 24 in the component relation diagram. Thus, since the viewpoints at the time of creating each drawing are different, the way of summarizing is partially different.

  FIG. 11 shows an embodiment of a program creation support apparatus 10 according to the present invention. As shown in the figure, in this embodiment, a domain analysis support tool 50, a program part management tool 60, a program part database 70, a unit test tool 71, and a PLC simulator 72 are provided. Note that the domain analysis support tool 50 may be omitted.

  The characteristic model editor 51 in the domain analysis support tool 50 analyzes the commonality and the difference of the product lineup in the development target domain, and the characteristic model (the product model) is an analysis model expressing the product lineup by “characteristics”. Characteristic information) 52 is created. That is, the editor creates the characteristic model shown in FIG. By creating this characteristic model, it is possible to analyze the commonality and the difference (the presence / absence of options, the presence / absence of parts that can be selected (substituted), etc.) and can be expressed in a diagram. Such a characteristic model is given to the program part management tool 60.

  The program parts management tool 60 includes a product parameter manager 61, a component manager 62, a macro processor 63, a component relation diagram editor 64, a component editor 65, and a work memory 66.

  The product parameter manager 61 manages a group of program parts necessary for constructing an application of a certain facility device or product, and an input parameter set (called “product parameter”) 67 to a macro described therein. To do. The present embodiment also has a function of creating product parameters based on the characteristic model created by the domain analysis support tool 50 and the product characteristic information.

  That is, an input parameter set (product parameter) 67 to a macro described to realize an application composed of various combinations that can be changed based on the difference is created. In the example described above, a macro input parameter for realizing the inspection apparatus A and a macro input parameter for realizing the inspection apparatus B are created. Of course, the applications that can be selected and generated are not limited to the inspection apparatuses A and B, and an inspection apparatus composed of a combination of other parts can also be generated. Therefore, input to a macro for realizing those inspection apparatuses is possible. Create parameters.

  The creation of the input parameter set 67 for this macro is to be automatically generated by recognizing product characteristic information and automatically extracting all selectable combinations based on the difference. Can do. However, according to such an automatically generating method, an unrealistic application is also constructed. For example, the characteristic model diagram shown in FIG. 9 is displayed on the display device, and the input device (not shown) is operated by the user. , A difference portion (selectable portion) is designated (black circle in FIG. 10). The product parameter manager 61 generates an input parameter to the macro based on the designated combination. Accordingly, when the user operates the input device to set a plurality of applications, an input parameter set (product parameter) 67 to the macro is generated.

  As shown in FIG. 12, the program parts database 70 stores product characteristic information and asset program information. The product characteristic information includes a characteristic model created by the domain analysis support tool 50 and characteristic selection data (which is an input parameter to the macro) that defines a combination of characteristics (corresponding to “input parameters to the macro”). . The asset program part information is registered for each component constituting each part. These components correspond to the individual components indicated by reference numerals 20 to 25 in FIG. 4, and the reference numerals with “a”, “b”, and the like are used as macros for indicating the changed parts and the changed contents. Is described in the upper component.

  Each component includes a component header, asset program parts associated with the component header, and a test scenario. The asset program part is a ladder program that is the basis for realizing the component. Based on this asset program part, a new program part with a part changed is created. If there is a place to change the ladder program of the asset program part, a macro description is incorporated. One function block is constructed for one component. The test scenario describes the input conditions to the program parts and the expected output in time series. Used when verifying the created user program (unit test).

  The component header has a data structure as shown in FIG. As is apparent from the figure, the component name, the realized characteristic list, the interface definition, the related component list, the program type, the program part file, the test scenario list, and the comment are constructed in order from the top.

  “Component name” describes the name of the component displayed in the component relation diagram editor. This component name is marked in the top column of the corresponding component.

  In the “list of realized characteristics”, a list of characteristics realized / implemented by the component is described. It is also the name of the property, and when displayed in the component relationship diagram editor, it is marked in the second column for that component. In the characteristic model diagram (FIG. 9 and the like), each characteristic is marked.

  The interface definition and the related component list are areas for defining a relation with the outside. In the “interface definition”, an input / output definition that can be used by other components is described. Specifically, variable names and data types, input / output distinction, and the like are described. In the “related component list”, a list describing components necessary for the operation of the component is described. For example, in FIG. 4, information specifying each component of the work carry-in part 21, the positioning part 22, the inspection part 23, and the work carry-out part 24 is described as a list in the components of the inspection apparatus 20. Thereby, the connection relation of each component can be understood, and the component relation diagram can also be reproduced.

  The program type and the program part file are component bodies, the “program type” describes the language in which the program part is mounted or the type of PLC model that can be executed, and the “program part file” The source code of the implemented program is described according to the program type.

  The test scenario list is information to be controlled and describes a list of a plurality of scenario files in which the input conditions to the program parts and the expected output are described in time series. As shown in FIG. 13B, this test scenario list is a table in which scenario IDs, test results, test scenario file names, and compatible characteristic selection data names are associated with each other. Here, the scenario ID is an identification number for uniquely identifying the test scenario, and the result (OK / NG) executed according to the test scenario and the untested state (-) are stored in the test result column. . The text scenario file name stores the file name of each text scenario. The compatible characteristic selection data name stores a file name of characteristic selection data that can be tested using the corresponding text scenario. That is, even with different characteristic selection data, the input conditions to the program component and the expected output time series data may be the same. In particular, each application that constitutes an application group may be upgraded, or may have a product lineup and have many common parts, so the same test scenario may be used even with different characteristic selection data. . Of course, a plurality of test scenarios may be prepared for one characteristic selection data.

  In the “comment”, a comment for understanding the content of the component is described. As described above, the component header links the asset program part and the test scenario stored in the component and associates them with other components.

  The unit test tool 71 can set a pair of virtual input and expected output given to the ladder part as a test case. The set “virtual input” is given to the PLC simulator 72, the simulation is executed, the output is compared with the expected output, and OK / NG of the test case is determined. The determination result is stored in the program parts database 70 via the component relation diagram editor 64 and the component manager 62.

  The PLC simulator 72 is an emulator that simulates and executes a programmable controller (PLC) on a personal computer. The downloaded ladder program is executed based on virtual I / O information given from the unit test tool 71.

  The component manager 62 accesses the program parts database 70 to read / write data. As an example, the required asset program parts according to the product parameters created by the product parameter manager 61 from the program parts database 70 storing the asset program parts (with macros) for creating the ladder program. The function of taking out 68 is provided. In addition, when a part not stored in the program part database 70 is newly created or an existing asset program part is edited, the newly created asset program part is stored in the program part database 70. .

  The macro processor 63 has a function of executing a modification of the ladder program according to the macro description and the product parameter, and generating a program component for a specific application. That is, associating the required specifications (characteristics) of the application with the difference part, as shown in FIG. 14, when a necessary asset program part is read and a macro description exists in the asset program part, Macro processing is executed based on the characteristic selection data that is an input parameter to the macro, unnecessary circuits in the ladder program are deleted, and a specific application program component described by a necessary and sufficient ladder circuit is generated. In the macro process, the change point defined in advance in the macro description is transformed using the characteristic selection data as an input parameter, and the macro processor 63 executes the process.

  As shown in FIG. 14, the asset program parts include a “read-only attribute flag” that specifies whether or not an actual program, a macro, and its child components are in an edit prohibited state, and a test. There is a “tested flag” for identifying whether the asset program part is completed and passed. The use of these flags will be described later.

  The component relation diagram editor 64 displays a component relation diagram (see FIG. 4), which is a diagram visually showing the relation between components, on the editor screen of the display device, and is edited and tested on the component relation diagram. A component is specified, and a component editor 65 as a component editing means and a unit test tool 71 as a test means are activated. The component relation diagram can be constructed by referring to the relation component list of the component header stored in the program database 70, for example, so that the relationship between the components can be understood. In other words, information that can build a component relation diagram is registered in the related component list. Similarly to the characteristic model, the component relation diagram may be registered in the program parts database 70 and read out.

  Specifically, in the activation process, as shown in FIG. 15, the component to be processed is selected from the component relation diagram displayed on the editor screen W of the component relation diagram editor 34 displayed on the display device. . For this selection, for example, the user operates the pointing device, moves the pointer on the editor screen W, places the pointer on the target component (“work loading portion” in the figure), and then clicks. Then, the component relation diagram editor 64 determines which component has been designated / selected from the coordinate position of the clicked position, and indicates that it has been selected (in the example of the figure, a circle is added to the vertex and the middle point). Display) and an input menu list ML for selecting a starting means (edit / unit test) is displayed. When “edit” in the input menu list ML is selected, the component editor 65 as an editing unit is activated. When “unit test” in the input menu list ML is selected, the component editor 65 is used as a test unit. The unit test tool 71 is activated. These processes are also performed by the component relation diagram editor 64.

  Further, the component relation diagram editor 64 obtains the asset program part (macro described) 68 of the designated component, and based on the component (hereinafter referred to as a parent component), a component derived from the source (hereinafter referred to as the parent component). , Child components and expressions). That is, it is determined whether or not there is a component (child) connected to the lower side in the component relation diagram of FIG. 15, and if it exists, the asset program part 68 corresponding to the child component is also read and each read The asset program parts are synthesized, and the synthesized program is stored in the work memory 66. In the example shown in FIG. 15, since the “work carry-in part” is selected, the components “supply part” and “load arm” connected to the lower part become child components, and the respective asset program parts are also read and synthesized. Is done. However, since only the “work carry-in part” that is the parent component is selected, in this embodiment, only the part of the asset program part for the parent component (work carry-in part) is selected. In other words, for the asset program parts corresponding to the child components (supply unit, load arm), the contents of the program (ladder circuit) can be viewed, but the editing process cannot be performed. Of course, the present invention is not limited to providing such a function, and this component may be editable.

  At this time, the component relation diagram editor 64 also has a function of storing and holding date and time information when stored in the work memory 66. In addition, the activated component editor 65 reads out the program (synthesized) stored in the work memory 66 and performs editing processing. When the editing process is completed, the component editor 65 stores the edited program in the work memory 66. The saved edited program is read by the component relation diagram editor 64, and the asset program part to be edited (after editing) is stored in the corresponding component file in the program part database 70 via the component manager 62. And update processing. When the component editor 65 does not perform the editing process, the component relation diagram editor 64 does not perform the update process to the program part database 70 described above. Whether the editing process has been performed is compared with the date / time information stored when the component relation diagram editor 64 saved in the work memory 66 and the date / time information at the time of saving for the current program. If they do not match, it is determined that the editing process has been performed. Of course, the determination of the presence / absence of the editing process is not limited to this, and various methods other than the sum check and storing the entire program before editing and comparing it can be adopted.

  The component editor 65 edits components and the like. In this embodiment, the component editor 65 edits ladder program parts including macro descriptions. That is, as one form of the component editor 65, there is a ladder editor (ladder programming tool). This embodiment has both a macro editing function and a ladder program editing function. FIG. 16 shows an operation screen of the activated component editor (ladder editor) 65.

  Next, the editing function will be described. In the present embodiment, the editing function is realized by the cooperation of the component relation diagram editor 64 and the component editor 65. Specifically, the flowcharts shown in FIGS. 17 and 18 are executed.

  First, the component relation diagram editor 64 recognizes a component designated (clicked with a pointer) by operating a pointing device, and acquires a component header of the component from the program parts database 70 via the component manager 62. .

  It is determined whether or not the “asset program part” file of the relevant component exists (S2), and if it exists, a list of the relevant component and its related child components is created (S3). As described above, this list can be created based on the related component list in the component header.

  Next, in accordance with the above list, the individual asset program part files listed in the list are extracted from the program part database 70 (S4), and the extracted individual “asset program part” files are synthesized to the component editor 65. One program file that can be recognized by the ladder programming tool. (S5).

  Other than the component designated by the user, that is, the program part (function block) corresponding to the child component is changed to a read-only attribute so that it cannot be edited (S6). That is, as shown in FIG. 14, a read-only attribute flag and a tested flag are set in the asset program part together with the program (with macro). Therefore, the read-only attribute flag is turned ON.

  Then, the program file is transferred to the component editor 65. Specifically, the one program file created in process step S5 (along with the read-only attribute flag ON information set in the process of S6) is stored in the work memory 66. At this time, the storage date is stored. Then, the component editor 65 is activated. If the branch determination in processing step S2 is No, that is, if the “asset program part” file of the corresponding component does not exist, a new “asset program part” file is created (S8). Each process from the above-described processing steps S1 to S8 is executed by the component relation diagram editor 64.

  Next, the component editor 65 loads the corresponding program file stored in the work memory 66, and displays the contents of the corresponding “asset program part” (function block ladder program) on the editor screen of the display device (FIG. 16). reference). The user operates a ladder programming tool (ladder editor) that is the component editor 65 to perform editing processing on the displayed ladder circuit, and thereafter ends the editing processing by the user (S10, S11). Then, the edited ladder program is checked whether or not the grammar is correct (S12), and the editing process is performed until the grammar is correct. The component editor 65 executes each processing from the above processing steps S10 to S12.

  When the component editor 65 is finished, it is determined whether or not there is a program change (S13). In the present embodiment, the saved date and time of the program file stored in the current work memory 66 is compared with the date and time information stored and held in the processing step S7. If they do not match, it was determined that there was a program change.

  If there is a program change, the tested flag of the component is turned OFF (S14), and the corresponding program is saved in the program part database 70 as an “asset program part” (S15). In other words, even if the unit test described later passes and the tested flag is ON, if the contents of the program are changed by editing processing, the tested flag is for the program before editing. , The flag is turned OFF, and the state is returned to the rejected state (here, the untested state). Accordingly, the test result column of the test scenario stored in the program parts database 70 is set to “−”. If the branch determination in process step S13 is No, that is, if there is no program change, the process is terminated as it is. Each process from the above-described process steps S13 to S15 is executed by the component relation diagram editor 64.

  FIG. 19 is a flowchart showing the function of the edit prohibition means. When the user designates the function block to be edited in order to perform the function block editing process in the processing step S10 in FIG. 18, the designated function block is recognized (S21), and the ladder circuit of the corresponding function is displayed. (S22). Then, it is determined whether or not the read-only attribute flag related to the corresponding function block is ON (S23). If the read-only attribute is ON, the edit mode is canceled (S26). Thereby, although the ladder circuit can be seen, the editing process is prohibited. If the read-only attribute is OFF, the process shifts directly to the edit mode (S24), waits for an edit command from the user, and edits (changes) the ladder circuit according to the input instruction (S25). The ladder programming tool which is the component editor 65 performs the functions shown in the flowchart shown in FIG.

  Next, the unit test function will be described. FIG. 20 shows a component relation diagram displayed by the component relation diagram editor 63 after a unit test is executed on some components. As shown in FIG. 20, the unit test function is executed, and a tested mark M is attached to a tested (passed) component or the display color is changed (both are performed in the figure). By changing the display form in this way, it is possible to see at a glance the component that “unit test is not executed” or “unit test is executed but NG” and the component that is completed after unit test is completed (OK). Can be identified.

  In this embodiment, the unit test function is realized by the cooperation of the component relation diagram editor 64, the unit test tool 71, and the PLC simulator 72. Specifically, the flowchart shown in FIG. 21 is executed.

  When the user operates the pointing device to specify a component and “unit test” in the input menu list ML is selected, the component relation diagram editor 64 recognizes the specified component and displays the component header of the component. Obtained from the program parts database 70 via the component manager 62 (S31). Next, it is determined whether or not the “asset program part” file of the corresponding component exists (S32). If it does not exist, an error is displayed (S37), and the process is terminated.

  On the other hand, if it exists, the characteristic selection data (requests the user to select) is taken out from the program parts database 70 (S33). That is, in this embodiment, input parameters (characteristic selection data) to a macro for generating a program component for a specific application for unit testing are manually specified. For example, there are many cases where it is desired to check whether or not a program edited by the editing processing function described above operates normally. In particular, when some ladder circuits corresponding to a macro are edited, it may be desired to preferentially test characteristic selection data related to the edited ladder circuit. Therefore, in order to satisfy such a requirement, the user specifies the component for which the unit test is to be executed and also specifies the characteristic selection data. Of course, the characteristic selection data stored in the program parts database 70 may be automatically executed so as to be sequentially extracted.

  Next, a “specific application program part” corresponding to the characteristic selection data designated by the user is generated (S34). The specific processing procedure of this processing step 34 executes the flowchart shown in FIG. That is, first, a list of the corresponding component and its related child components is created (S41). Such processing is the same as the processing step S3 in the editing processing. Then, in accordance with the above list, each “asset program part” file is extracted from the “program part database 70” (S42). Such processing is the same as the processing step S4 in the editing processing.

  Thereafter, macro processing is performed by the macro processor 63 using the designated characteristic selection data (input parameters to the macro) to convert “asset program parts” into “specific application program parts” (S43). Here, the corresponding characteristic selection data includes not only the specified component but also the characteristic selection data for the child component when there is a child component. In other words, the characteristic selection data extracted in accordance with the selection by the user in S33 is also specified for the child component and extracted. Then, the files of the individual “specific application program parts 73” are combined into one program file (S44).

  In this way, the program component for the specific application is generated. That is, when there is no child component, the specific application program part is composed of a program file composed of one specific application program part generated from the originally specified one component. If there exists a program component for a specific application based on each component, one program file is generated.

  Next, the component relation diagram editor 64 retrieves, from the program part database 70, the test scenario corresponding to the “program part for specific application” generated by executing the processing step 34 via the component manager 62 (S35). ). The specific processing procedure of this processing step 35 executes the flowchart shown in FIG. That is, first, the component relation diagram editor 64 acquires a test scenario list from the corresponding component header stored in the program parts database 70 via the component manager 62. That is, when a child component exists, a test scenario for the child component is also acquired. Then, a test scenario that matches the characteristic selection data is extracted from the acquired test scenario list (S52). That is, as shown in FIG. 13B, the test scenario list name column of the component header describes the compatible characteristic selection data name, so that the test scenario file name that matches the specified characteristic selection data is displayed. All can be extracted and acquired.

  The component relation diagram editor 64 displays the extracted “test scenario file name matching the specified characteristic selection data” on the display screen as a candidate test scenario, and prompts the user to select a test scenario to be executed this time (S53). ). If the user selects it, a test scenario file corresponding to the selected test scenario name is acquired (S54).

  The component relation diagram editor 64 passes the corresponding program file and test scenario acquired by executing the above processing steps S34 and S35 to the single tool (S36). Then, the single tool executes a test based on the acquired program file and the test scenario (S38). The specific processing procedure of such a test executes the flowchart shown in FIG. That is, first, the unit test tool 71 downloads the corresponding program file to the PLC simulator 72 (S61), and starts the execution of the PLC simulator 72 (S62). Next, the unit test tool 71 sequentially executes the test scenarios (S63). It is determined whether or not the scenario has ended (S64). If it has not ended, the input is changed according to the scenario (S65). As the input is changed, the PLC simulator 72 executes the calculation and outputs it, so that the single tool 71 records the output and compares it with the assumed scenario result (S66). Then, as a result of the comparison, it is determined whether or not the output is within the assumption, that is, whether or not the output matches the assumption result (S67). If within the assumption, the process returns to processing step S63 to execute the next scenario. To do.

  If the branch determination in process step 67 is No, that is, if the output obtained by the PLC simulator 72 does not match the expected result, the test result for this test scenario is set to NG (S68). In addition, if the branch determination at processing step 64 results in Yes, it means that the scenario has been executed to the end and the results of all outputs have coincided with the expected results, so the test results for this test scenario are OK. (S69).

  When the test with the unit test tool using the selected test scenario for the specific application program part based on the characteristic selection data specified in this way is completed, the test result is the result of the corresponding test scenario in the test scenario list. (S39). That is, when the unit test tool 71 completes the test based on the corresponding program file and the test scenario passed from the component relation diagram editor 64, the unit test tool 71 passes the test result to the component relation diagram editor 64. The received test result (OK / NG) is stored in the test result column of the test scenario list name of the corresponding component header.

  The component relation diagram editor 64 adds a tested mark M as shown in FIG. 20 or changes the color to components whose test results of all test scenarios are OK (S40). As a result, it is possible to find at a glance a component that has not been tested (the test results of all test scenarios are OK) by simply looking at the component relation diagram. Therefore, the user can find a component to be edited or unit tested, and can smoothly execute the necessary processing. The components that have passed the test are originally completed in the program and do not need to be corrected, but can be edited using the editing function. In such a case, the execution of the processing step S14 in FIG. 18 turns off the tested flag, so the test results of all test scenarios do not satisfy the OK condition. A process of deleting M or returning the color to the original state is performed.

  As a result, even if the component has passed the unit test once, if the editing process is performed after that, there is no guarantee that the ladder circuit rewritten by the editing will operate normally. Become. Therefore, the user can execute the unit test again and determine whether or not the edited component passes the test.

  In the above-described embodiment, the display form (marking or color change) that indicates that the component that has passed has been passed is used, and those that have not passed (failed and untested) remain in the basic display form. However, for those that have not passed, different display forms may be adopted so as to further distinguish between failed and untested.

  The passed specific application program part is stored in a specific PLC, and the PLC cyclically executes the specific application program part (ladder program) to control a specific application which is a part of the inspection apparatus. In addition, based on a plurality of program parts for specific applications that have passed, a program is created by synthesizing them, and the necessary destination is made. Thereafter, the synthesis program is stored in the PLC, and the PLC executes the synthesis program cyclically to arbitrarily control the entire inspection apparatus.

It is a figure explaining the analysis of the commonality and difference of a product. It is a figure which shows the structure of the test | inspection apparatus which is one form of an application. It is the figure which showed the variation of the characteristic in an inspection apparatus with a table form. It is a whole block diagram of a component. It is a figure explaining an option component. It is a figure explaining an alternative component. It is a figure which shows an example of the function block which describes an option component. It is a figure which shows an example of the function block which describes an alternative component. It is a whole figure of a characteristic model. It is a figure which shows the selection state of an option component and an alternative component in a characteristic model. It is a figure which shows one embodiment of this invention. It is a figure which shows an example of the information stored in a program components database. It is a figure which shows an example of the data structure of a component header. It is a figure explaining the effect | action and principle of a macro process. It is a figure which shows an example of the display screen in a component related figure editor. It is a figure which shows an example of the operation screen of a component editor. It is a part of flowchart which shows an example of an edit function. It is a part of flowchart which shows an example of an edit function. It is a flowchart explaining the function of an edit prohibition process. It is a component related figure which shows an example of the display form in which the test result was reflected. It is a flowchart which shows the process sequence of a unit test. It is a flowchart which shows the specific process sequence of S34 of FIG. It is a flowchart which shows the specific process sequence of S35 of FIG. It is a flowchart which shows the specific process sequence of S38 of FIG.

Explanation of symbols

50 Domain support analysis tool 51 Characteristic model editor 52 Product characteristic information 60 Program parts management software 60 Program management tool 61 Product parameter manager 62 Component manager 63 Macro processor 64 Component editor 65 Component editor 66 Work memory 67 Macro Input parameters (characteristic selection data)
68 Asset program parts (macro description completed)
70 Program Parts Database 71 Unit Test Tool 72 PLC Simulator 73 Program Parts for Specific Applications

Claims (8)

A test scenario that describes multiple asset program parts for configuring a device control program, and the input conditions and expected output to a specific application program part generated based on the asset program parts in time series And a program component storage means for storing
A selection means for displaying a related diagram showing a connection relation of the asset program parts on a display device, and selecting an asset program part to be processed and a processing content;
Editing means for editing the asset program part;
Test means for giving an input condition according to the test scenario to the simulator in which the specific application program part is downloaded, and comparing the execution result of the simulator with the expected output;
With
The asset program part is a program part including a change point as a macro description when a change point expected in advance exists.
The specific application program component corresponding to the asset program component including the macro description is generated by executing macro processing,
The display mode of the asset program parts on the related diagram is configured to reflect the comparison result by the test means,
A program component management apparatus characterized by the above. It is determined whether or not there is a child asset program part in the asset program part selected by the selection means, and when the child asset program part exists, the asset program part and the child asset program Having a program synthesis means for synthesizing parts and generating one program;
2. The program component management apparatus according to claim 1, wherein the editing unit performs an editing process on the program synthesized by the program synthesizing unit. 3. The program component according to claim 2, further comprising a prohibition unit configured to permit display of the contents of the program for the child asset program component, but to prohibit editing by the editing unit. Management device. It is determined whether or not there is a child asset program part in the asset program part selected by the selection means, and when the child asset program part is present, the specific program corresponding to the asset program part is determined. Program synthesis means for synthesizing the application program component and the specific application program component corresponding to the child asset program component to generate one program,
4. The program management apparatus according to claim 1, wherein the specific application program component downloaded and executed by the simulator is a program generated by the program synthesis unit. 5. The reflection result of the comparison by the test means is to enable identification of a test that has passed a test scenario and a test that has not passed, according to any one of claims 1 to 4. The program management apparatus described. It has been determined whether or not the asset program part displayed in the display mode of the passed thing has been edited by the editing means, and when edited, the means for changing the display mode to a state that has not passed The program management apparatus according to claim 5, wherein: The program management apparatus according to claim 5 or 6, wherein when all the test scenarios prepared for the asset program parts are passed, the asset program parts are passed. The asset program part is configured by a ladder program,
The program management according to any one of claims 1 to 7, wherein the change point is a macro description in a macro processing language intended to rearrange contacts and circuits of the ladder program. apparatus.

Images