Hierarchical accumulated validation system and method

The present disclosure generally relates to improvements in validating control specifications and more particularly pertains to a system and method to hierarchically validate graphically based executable logic control specifications. This method may include identifying, by a processor for hierarchically validating a graphically based logic control specification, a functional hierarchy of a first application of the control specification comprising a first feature. The method may include executing, by the processor, a specific first feature test case on the first feature to at least one of validate a structure of the first feature and validate that a specific functional requirement of the first feature is met.

BACKGROUND

The present disclosure relates generally to improvements in validating control specifications and more particularly pertains to a system and method to hierarchically validate graphically based executable logic control specifications.

2. Description of the Related Art

As demand grows for new in-vehicle features, a large number of electronic control modules are being introduced in the automobile to increase passenger's comfort, safety, entertainment and overall performance. The performance parameters of features such as electronic power steering, engine management systems, anti-lock braking systems, airbag systems, transmission systems, and navigation and entertainment systems are monitored and controlled by electronic control units (ECUs). Vehicle level ECU design and testing for small hardware or software changes is expensive and computationally intensive. Historically, module level tests have proved insufficient and are unable to be used to validate an entire ECU. Thus, a more efficient and inclusive system and method of validating designs to comply with a standard is desired.

SUMMARY

The above disclosed needs are successfully met via the disclosed system and method. The present disclosure is generally directed to a system and method to hierarchically validate a graphically based executable logic control specification designed to comply with a standard, such as an ISO standard.

In various exemplary embodiments, a computer-based method, a system, and an article of manufacture including a non-transitory, tangible computer readable storage medium having instructions stored thereon is disclosed. This computer-based method may include identifying, by a processor for hierarchically validating a graphically based logic control specification, a functional hierarchy of a first application of the control specification comprising a first feature. The computer-based method may include executing, by the processor, a specific first feature test case on the first feature to at least one of validate a structure of the first feature or validate that a specific functional requirement of the first feature is met. Also, this computer-based method may include executing, by the processor, a specific first application test case on the first application to validate a functional requirement of the first application is met.

This computer-based method may also include executing, by the processor, a specific second feature test case to a second feature to at least one of validate a structure of the second feature or validate that a specific functional requirement of the second feature is met. The functional hierarchy may comprise the second feature. Additionally, the validation of the second feature may include the validation of the first feature. The first feature generally includes one or more modules. The computer-based method may include translating text based code into graphically based logic and/or translating graphically based logic into text based code. This computer-based method may include validating all of the applications in the control specification and/or validating an entire electronic control unit, such as an ECU of a vehicle. The vehicle may be any type of vehicle.

Additionally, this computer-based method may include identifying, by the processor, a functional hierarchy of the first feature of the first application. The validation process may start at the end of the control specification and validate to the beginning. A unique feature test case may be developed to validate each feature's unique functional requirement. In various exemplary embodiments, the hierarchical validation process flows from module level, to feature level, to application level. Based on computational constraints, functional hierarchies may be subdivided. Substantially exhaustive validation coverage may be achieved by overlapping test case findings. In an embodiment, each feature may be a function within the application and/or the graphically based logic control specification.

This computer-based method may be used to validate a system to an International Organization for Standardization (ISO) specification. The graphically based logic control specification data may be rendered on a user interface. The computer-based method may include executing, by the processor, a specific first application test case on the first application to validate that a specific functional requirement of the first application is met.

DETAILED DESCRIPTION

In the Automobile industry, an electronic control unit (ECU) is an embedded electronic device, such as a digital computer, that read signals coming from sensors placed at various parts/locations and in different components of the car (SeeFIG. 1A). Depending on this signal data, the ECU controls various units (e.g. engine) and automated operations within the car and also keeps a check on the performance of some key components used in the car.

An ECU generally comprises hardware and software (firmware). The hardware may comprise various electronic components on a printed circuit board (PCB). These components may further comprise a microcontroller chip along with an EPROM or a flash memory chip. The software (firmware) may be a set of lower-level codes that are processed by the microcontroller.

Many times, in the industry, an ECU (Engine Control Unit) may be referred to as an ECM (Engine Control Module). The ECM, also known as EMS (Engine management system), is an ECU in an internal combustion engine that controls various engine functions such as fuel injection, ignition timing and idle speed control system. This control may be based on data (like engine coolant temperature, air flow, crank position, etc.) received from various sensors (SeeFIG. 1B). The ECM may also “learn about” the engine as the car is driven. The “learning” is actually a process that the ECU uses to track the tolerance changes of the sensors and/or actuators on the engine. The ECM stores these “learned” values in battery backed-up RAM so that it doesn't have to start from scratch the next time the engine is turned over. In the aeronautical applications these systems (ECM equivalents) are popularly called as ‘FADECs’ (Full Authority Digital Engine Control). Referring toFIGS. 1A and 1B, an exemplary vehicle is shown including an ECU200. As depicted inFIG. 1B, the ECU200may be configured to receive input from sensors and to receive input directly from a user, e.g. driver of the vehicle.

The creation of a complete ECU200is an intensive process that requires rigorous, planning, testing, and verification. Often times, the design of the ECU200or parts of the ECU200may be aided through use visual programming language (VPL), Model Based Development (MBD) and/or graphically based executable logic. In computing, a visual programming language is any programming language that lets users create programs by manipulating program elements graphically rather than by specifying them textually. VPL allows programming with visual expressions, spatial arrangements of text and graphic symbols, used either as elements of syntax or secondary notation. For example, many VPLs (known as dataflow or diagrammatic programming) are based on the idea of “boxes and arrows”, where boxes or other screen objects are treated as entities, connected by arrows, lines or arcs which represent relations.

VPLs may be further classified, according to the type and extent of visual expression used, into icon-based languages, form-based languages, and diagram languages. Visual programming environments provide graphical or iconic elements which can be manipulated by users in an interactive way according to some specific spatial grammar for program construction.

The VPL based design and operation of the ECU200may be intended to conform to a specification. Verification and validation may be independent procedures that are used together for checking that a product, service, or system, such as the complete ECU200or that portions of the ECU200, meet requirements and specifications and fulfill its intended purpose. In some cases, these are components of a quality management system, such as ISO 9000. In various embodiments, verification and/or validation may be performed by a third party. Verification may check that a product, service, or system (or portion thereof, or set thereof) meet a set of initial design requirements, specifications, and regulations. In the development phase, verification procedures involve performing special tests to model or simulate a portion, or the entirety, of a product, service or system, then performing a review or analysis of the modeling results. In the post-development phase, verification procedures involve regularly repeating tests devised specifically to ensure that the product, service, or system continues to meet the initial design requirements, specifications, and regulations as time progresses. It is a process that is used to evaluate whether a product, service, or system complies with regulations, specifications, or conditions imposed at the start of a development phase. Verification can be in development, scale-up, or production. This is often an internal process.

Validation may be used to check that development and verification procedures for a product, service, or system (or portion thereof, or set thereof), such as the complete ECU200or that portions of the ECU200, result in a product, service, or system (or portion thereof, or set thereof) that meets initial requirements, specifications; and regulations. For a new development flow or verification flow, validation procedures may involve modeling either flow and using simulations to predict faults or gaps that might lead to invalid or incomplete verification or development of a product, service, or system (or portion thereof, or set thereof). A set of validation requirements, specifications, and regulations may then be used as a basis for qualifying a development flow or verification flow for a product, service, or system (or portion thereof, or set thereof). Additional validation procedures may also include those that are designed specifically to ensure that modifications made to an existing qualified development flow or verification flow will have the effect of producing a product, service, or system (or portion thereof, or set thereof) that meets the initial design requirements, specifications, and regulations; these validations help to keep the flow qualified. It is a process of establishing evidence that provides a high degree of assurance that a product, service, or system accomplishes its intended requirements. This often involves acceptance of fitness for purpose with end users and other product stakeholders. Written requirements for verification and/or validation may be created as well as formal procedures or protocols for determining compliance in accordance with this disclosure.

Verification that the ECU200design conforms in every possible permutation to the specification can be very difficult if not impossible and tax even the most advanced computing system. In general, in various exemplary embodiments, the present system validates from the traditional end of the specification to the beginning of the specification. For instance, the present system validates the entire ECU200control specification using a functional hierarchy validation of the graphically based executable logic. In an exemplary embodiment and with reference toFIG. 2, this hierarchy approach may move from the Module level50to the Feature level75to the Application level100to validate the entire ECU200control specification.

Module level50may comprise the lowest level within a feature80. A module55may represent actual control logic, that is, the functional requirement of module55will generally comprise the logic itself. A combination of multiple modules55may result in a higher order functional requirement that may be evaluated. The combination of multiple modules55may result in feature80. Validation performed on the Module level50may include low level control specification and low level functional requirements, for instance those related to structure. The Feature level75may comprise functions within an application105. A feature80may be conceptualized as a function and/or subassy. For instance, the functional requirement associated with a feature80may be controlling the mode of the vehicle. The feature80controlling the mode of the vehicle may comprise many modules55that each determine and control elements within this function. Feature level75may comprise a functional hierarchy such as a module55and/or groups of modules55. Since there is no dual use of modules55contemplated (overlap between functional hierarchies) an accumulative hierarchical approach may be performed with confidence of the results achieved. The Feature level75may comprise specific mid level functional requirements. The Feature level75may comprise a combination of actual control logic to perform a function. The Feature level75may comprise multiple layers of modules55based on complexity. The Application level100may comprise the entire specification. The Application level100may comprise functional hierarchies (such as a feature80and/or groups of features80). The Application level100may comprise a combination of the features80to perform a general function.

In various embodiments, this system utilizes two validation categories: low-level validation and high-level validation. The low-level validation may comprise identification of structural and low-level functional issues (e.g. range violations, block design issues, dead code, etc.). This low-level validation may be configured to achieve module design functional correctness.

High-level validation may validate the feature80and the application105functional hierarchies to identify and correct control design issues (e.g. incorrect control theory, unintended design error, etc.). This high-level validation may be configured to achieve control design correctness.

In general, there are two validation stages and/or levels, the Feature level75and the Application level100. The Feature level75may include structural and functional requirements. The Application level100may comprise functional requirements.

With reference toFIG. 3A, an exemplary process flow is depicted. This process flow may be read left to right top to bottom, (following the provided arrows). Note, that the calculations depicted in the graphically based executable logic generally flow from left to right. However, the validation of established functional hierarchies is intended, in various exemplary embodiments, to be performed right to left.

Initially, these Application level100graphically based executable logic functional hierarchies are identified. Next, the features80comprised within the functional hierarchies are identified. An individualized test case to evaluate the structure of each feature80may be created (such as, test case 1a.1). Additionally, the functional requirement associated with each feature80(such as, functional requirement (FR) 1a.1) is identified. The associated test case (e.g., 1a.1) may include this testing of the functional requirement. Next, an individualized test case to evaluate the structure of the next feature80in the hierarchy may be identified (such as, test case 1a.2). Additionally, the functional requirement associated with each feature80(such as, functional requirement (FR) 1a.2) is identified. The associated test case (e.g., 1a.2) may include this testing of the functional requirement. This process is repeated until all of the test cases (1a) on the features80within the functional hierarchy at this level are generated.

In response to a test case being created (e.g., test case 1a.1), validation testing on that test case may be performed, such as running test case 1a.1. This validation testing may test that the structure is correct and that any associated functional requirement is met. In response to the feature80passing this validation testing, the validation test of the next feature80in the functional hierarchy is performed. This validation test may be inclusive with respect to the previously completed prior functional requirement validation performed within the functional hierarchy. This inclusive process reduces computational requirements. Also, individualized test cases specific to a discrete structure and/or functional requirement reduces overall computational requirements. Also, in various embodiments, once the module55or the feature80is validated, only higher level functional requirements need be performed. Stated another way, in various embodiments, subsequent lower level validation at this level is not needed nor performed on the module55or the feature80.

In response to all of the features80in the functional hierarchy being validated, a test case of the application105may be determined and run on the Application100level, similar to the test cases run on the Feature75level. At the Application100level, the test cases are generally not concerned with structure checking as that has been covered in the validation of the Feature level75.

Various elements of the present system may be performed on a computer based simulator and/or contained within simulation software, such as Simulink™. Test cases at the Feature level75may be designed to achieve coverage targets, such as Simulink™ design verification (SLDV) level then progress using this hierarchical approach to a modified condition decision coverage (MCDC) level. Modified condition decision coverage may include substantially every path the logic may take and/or cover all functional requirements of the control specification. In various embodiments, modules are validated in response to MCDC targets being met and/or functional requirements not being violated. Violations of functional requirements result in addressing and/or correcting the module55errors.

Test cases at the Application level100may further be designed for specific functional checking (user, sensors such as a LA4 Lambda Meter, etc.). The Feature75and Application100levels may be validated when functional requirements are not violated. Functional requirement violations may result in addressing/fixing control design errors. A functional validation for the final feature80validation test (e.g., complete feature80) and The Application level100validation may be performed in this stage.

With renewed reference toFIG. 3A, in various embodiments, the Feature level75may include low-level and high-level validation of the features80(e.g., structural and functional validation of features80). For instance, MCDC for the feature80functional hierarchy and MCDC plus functional for a complete feature80. Functional requirements may be added and/or evaluated as logic is evaluated. Each functional requirement may comprise multiple functional hierarchies. If a functional hierarchy does not include a functional requirement it may be included with another functional hierarchy for validation flow purposes.

With reference toFIG. 3B, a graphical representation of test cases being run on the Application level100are depicted. For instance, test cases 3.1-3.5 each depict a unique identified functional hierarchy. A test case may be developed to test and/or validate the functional requirement associated with each functional hierarchy. With reference toFIG. 3C, test cases established inFIG. 3Bare executed. For instance, test case 3.1 is performed. If test case 3.1 returns no errors, then test case 3.2 may be run. This is also an example of the process moving right to left, starting at the end of the specification. This test case (3.2) may optionally include the results of test case 3.1, (3.2+3.1). In this way, the body of knowledge is increased without overtaxing the computing system processing each test case.

With reference toFIG. 4, in various embodiments, the feature80functional hierarchy may not be defined in the control specification. Based on computational limitations, the user may select a functional hierarchy based on the functional requirements. For instance, in the scenario where a functional hierarchy comprises one module55(or a computationally, manageable number of modules55) the validation may be accomplished in one test run. In the scenario where a functional hierarchy is too large and/or complex, the functional hierarchy should be subdivided into smaller units for validation.

With reference toFIG. 5, in various embodiments, the Application level100comprises an Application level100functional hierarchy. The Application level100functional hierarchy may be validated on all functional hierarchies of the Feature level75. The test cases for the Application level100should include new functional test cases and the feature80final functional hierarchy coverage test cases for improved and substantially exhaustive test coverage. Functional requirements may be added and/or evaluated as logic is validated. For instance, each functional requirement may utilize multiple functional hierarchies.

With reference toFIG. 6, in general, as previously stated, the validation system starts at the end and progresses to the Application level100functional hierarchy. For each feature80within a functional hierarchy, a Feature level75validation may be performed. In response to all features80within a functional hierarchy being validated, the Application level100validation for the functional hierarchy may be performed. This validation may build upon the accumulated validation of the Application level100functional hierarchy. In response to functional requirement violations being found within a functional hierarchy, low-level validation may be performed on the modules of interest and/or high-level validation should be re-done on the functional hierarchy. In some scenarios, the feature80validation may not follow the Application level100functional hierarchy order.

With reference toFIG. 7in various exemplary embodiments, in response to substantially best possible coverage (MCDC) being achieved for a module55, additional unique testing may result in improved exhaustive coverage. This additional testing may be performed to improve the confidence in the accuracy of the validation. This additional testing may be performed in the Feature level75and/or the Application level100to result in improved exhaustive coverage confidence.

A best possible coverage test case may be generated for each functional hierarchy separately. These test cases may be user defined or may be defined by formal methods. A test case may be generated for the level that has not yet been validated. Previously validated logic may be combined with currently targeted logic, thus validated logic may be accumulated and aggregated over time as more test cases are processed. Also, functional requirements may be added and validated as one progresses up hierarchy levels. Using best possible coverage test cases and test cases generated for specific functional checking, functional requirements may be validated. Stated another way, this system validates the feature level functional hierarchy first and then moves to the Application level100functional hierarchy validation utilizing the same concept. In various embodiments, the system is performed using graphic based logic.

Starting at the end of the specification and validating to the beginning allows a non-validated functional hierarchy to be validated utilizing best possible coverage techniques while maintaining validated functional hierarchies for higher level functional requirement checking. Generating test cases for each functional hierarchy separately reduces processing requirements and gives coverage results for a targeted functional hierarchy. This allows each functional hierarchy to be validated directly (lower level functional requirements) while including all eligible functional requirements (typically higher level functional requirements). This system provides the possibility to achieve a more comprehensive exhaustive testing when formal methods cannot be applied due to computational or mathematical limitations. In response to this process being completed on all of the Application level100functional hierarchies, the entire specification is validated to the best possible coverage and exhaustive metrics. This process and system may validate the application logic of the entire ECU200, such as for ISO compliance. This ISO compliance can be to any suitable ISO specification. This ECU200may be used in a vehicle, such as a land vehicle, water craft or aircraft. The ECU200may be used in a car, an electric bicycle, motorcycle, scooter, four wheeler, atv, motorhome, train, ship, boat, aircraft, and/or spacecraft.

The graphically based executable logic may be converted to and from text logic at any desired time. For instance, in response to the entire ECU200being validated, the logic may be translated from graphically based executable logic to text based logic. Also, in response to the entire ECU200being validated, the logic may be passed on to software in the loop and/or hardware in the loop simulation for further verification/validation. Also, various aspects of this disclosure may be combined with rapid prototyping to further test the ECU200logic and/or the ECU200elements.

Steps described for one embodiment of a validation system may additionally or alternatively be incorporated into any of the other embodiments. For example, the steps described pertaining toFIG. 3A, may be used in any other embodiments. Those of ordinary skill would also appreciate that the various illustrative logical blocks, modules, and algorithm steps described in connection with the examples disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosed apparatus and methods.

The steps of a method described in connection with the examples disclosed herein have been disclosed as pertaining to the ECU200; however, this method is applicable to any graphically based executable logic and/or hierarchical validation of graphically based executable logic control specifications. For instance, with reference toFIGS. 8 and 9, .mdl files and functional hierarchies at the application level and feature level for any type of control specification are depicted.

As will be appreciated by one of ordinary skill in the art, the system may be embodied as a customization of an existing system, an add-on product, upgraded software, a stand alone system, a distributed system, a method, a data processing system, a device for data processing, and/or a computer program product. Furthermore, the system may take the form of a computer program product on a non-transitory computer-readable storage medium having computer-readable program code means embodied in the storage medium. Any suitable computer-readable storage medium may be utilized, including hard disks, CD-ROM, optical storage devices, magnetic storage devices, and/or the like.