BEHAVIOR VERIFICATION FOR SYSTEMS MODELED WITH FINITE STATE AUTOMATICS

Abstract

A method for verifying system behavior and correcting design flaws in a system modeled with a finite state machine (FSM) or another representation method, which involves receiving system design-related data from a user device via a model verification platform. The data describes states, state transitions, events, and outputs of the FSM-modeled system. The method includes searching the data for a predetermined behavior of the FSM-modeled system, including one or more predetermined states and / or mode changes. The method includes marking the predetermined behavior as verified and performing a control action in response to the verified behavior, including transmitting a notification to the user device indicating the verified behavior and, if appropriate, a design recommendation.Instructions for the procedure can be recorded in a computer-readable storage medium and executed by a processor to cause the model verification platform to perform the procedure.

Description

INTRODUCTION

[0001] The present disclosure relates to a supporting software-based "toolbox" to assist the design and implementation of systems modeled with finite state machines (FSMs) and exhibiting multiple states, state transitions / mode changes, and other potentially complex behavior. The present approach is intended to assist system designers, programmers, and other users during the system design process by identifying potential design errors and providing corrective recommendations where necessary. In addition to behavioral aspects such as state or mode transitions, other features such as interface indicators (icons, indicator lights, light bars, etc.), interaction schemes (push buttons, level controls, etc.), alarms and warnings, general behaviors and conditions (response to traffic control devices or lack thereof), and escalation protocols for automated vehicle behavior (e.g.,Minimum risk maneuvers (MRM) while driving and minimum risk conditions (MRC) such as roadside parking) are taken into account.

[0002] As known in the field, finite-state machines are mathematical abstractions widely used to develop and validate the behavior of a wide variety of software programs and physical systems. A finite-state machine can be represented graphically as a state flow diagram, a state transition table, or a hierarchical statechart such as a Statechart. Systems modeled with FSM begin with an initial state. Based on the current state of the designed system and a specific single event or combination of events ("superevents"), a finite-state machine can transition between various additional states in response to system inputs or triggering events.Although the above-mentioned and highly valued state transition tables or state flow diagrams are crucial for the overall system design process, a resulting system design may still exhibit suboptimal or incorrect design structure and behavior. DESCRIPTION

[0003] This document describes automated systems and associated methods to assist a user, e.g., a software programmer, designer, or system developer, in verifying the system behavior of a system modeled with a finite state machine (FSM). The automated methodology considered here is particularly well suited to the design of systems with relatively complex and / or highly interactive behavioral characteristics, e.g., a wide range of possible states, state transitions, state- or mode-triggering events, and outputs. For example, motor vehicles with automatic control have relatively complex operating modes and state transition rules. Some of these modes are executed automatically / autonomously or in response to driver inputs, while others may rely on timers, hidden logic, or other automatically occurring activation criteria. Other complex systems, such asAvionics, process control automation, medical devices and the associated control logic for a wide range of mobile or stationary systems are developed using finite state machine techniques and would also benefit from the automatic verification procedure described in detail below.

[0004] According to an exemplary embodiment, a method for verifying the behavior of a system modeled with a finite state machine (FSM) comprises receiving data associated with a design of the FSM-modeled system from a user device via a model verification platform, wherein the data describes states, state transitions, events, and outputs of the FSM-modeled system. The method also includes searching the data via the model verification platform for predetermined behavioral characteristics of the FSM-modeled system, wherein the predetermined behavior comprises one or more predetermined state and / or mode transitions of the FSM-modeled system, and marking the predetermined behavior in a memory of the model verification platform as verified behavior.The method additionally comprises performing a control action in response to the verified behavior, including transmitting a notification to the user device indicating the verified behavior.

[0005] Receiving the data associated with the design of the FSM-modeled system may include receiving a state transition table or a state flow diagram.

[0006] The verified behavior could involve problematic behavior, in which case the notification contains information related to the location of the problematic behavior within the data. Performing the control action may involve automatically generating one or more recommendations to address the problematic behavior.

[0007] The predetermined behavior according to one or more embodiments includes structural hierarchy properties. The structural hierarchy properties may include, for example, nesting, global events, and / or event consistency properties. The predetermined behavior may also include correctness properties, such as, but not limited to, system behavior properties, system control properties, and / or cognitive properties. The predetermined behavior of the FSM-modeled system, in some embodiments, includes non-deterministic system behavior properties representing two or more distinct states having a behavioral manifestation.

[0008] A model verification platform is also disclosed herein. One embodiment of the model verification platform includes a system design module configured to receive data associated with a design of an FSM-modeled system from a user device, wherein the data describes states, state transitions, events, and outputs of the FSM-modeled system. A search module is configured to search the data for a predetermined behavior of the FSM-modeled system, wherein the predetermined behavior comprises one or more predetermined state and / or mode transitions of the FSM-modeled system. An identification / labeling module is configured to mark the predetermined behavior in the memory of the FSM-modeled system as a verified behavior.A design suggestion module is configured in this embodiment to perform a control action in response to the verified behavior, including transmitting a notification to the user device indicating the verified behavior.

[0009] Also described herein is a non-transitory computer-readable storage medium having recorded thereon computer-readable instructions that, when executed by one or more processors of a model verification platform, cause the one or more processors to implement the method summarized above. For example, the processor(s) could receive from a user device data associated with a design of an FSM-modeled system, the data describing states, state transitions, events, and outputs of the FSM-modeled system and including a state transition table or state flow diagram.The processor(s) could be caused to search the data via the model verification platform for a predetermined behavior of the FSM-modeled system, wherein the predetermined behavior includes one or more predetermined state and / or mode transitions of the FSM-modeled system, and to mark the predetermined behavior as verified behavior. As part of this implementation, the processor(s) could be caused to perform a control action in response to the verified behavior, including transmitting a notification to the user device indicating the verified behavior and containing recommendations for correcting at least a portion of the verified behavior.

[0010] The above features and advantages, as well as other features and associated advantages of this disclosure, will become readily apparent from the following detailed description of illustrative examples and modes for carrying out the present disclosure, when considered in conjunction with the accompanying drawings and the appended claims. Furthermore, this disclosure expressly includes combinations and subcombinations of the elements and features presented above and below. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings, which are incorporated in this specification, illustrate implementations of the disclosure and, together with the description, serve to explain the principles of the disclosure. The accompanying drawings are not necessarily to scale and may present a somewhat simplified representation of various preferred features of the present disclosure as disclosed herein, including, for example, specific dimensions, orientations, positions, and shapes. Details associated with such features will be determined in part by the particular intended application and environment of use. Fig. 1 shows an automated system for use in designing and implementing a system using finite state machine (FSM)-based design techniques, the automated system being configured to verify and help correct the behavior of the designed system in accordance with the disclosure. Fig. 1A shows an exemplary embodiment of distributed processing nodes for use in implementing portions of the Fig. 1 automated system. Fig. 2 shows a method for verifying behavior according to the disclosure. Fig. 3 is a flowchart of a method for verifying system behavior according to an embodiment of the disclosure. DETAILED DESCRIPTION

[0012] The present disclosure may be embodied in many different forms. Representative examples of the disclosure are illustrated in the drawings and are described in detail herein as non-limiting examples of the disclosed principles. To this end, elements and limitations described in the "Summary," "Introduction," "Summary," and "Detailed Description" sections, but not explicitly recited in the claims, should not be incorporated into the claims, individually or collectively, by implication, inference, or otherwise.

[0013] With reference to the drawings, in which like reference numerals refer to like features in the several views, Fig. 1 an automated system 10 configured to verify the behavior of a system modeled with a finite state machine (FSM). Since it is crucial to achieve the most perfect understanding and implementation of a designed system in the design process and to develop systems that are free from faulty structures that can lead to design errors and incorrect user interaction, it is useful to verify whether the designed system and the associated human-machine interfaces behave in a logical manner and whether their behavior is as expected by a user 11, e.g., a designer or programmer, as opposed to a driver, pilot, or other end user of a physical embodiment of the modeled system.

[0014] To this end, the present solutions enable the user 11 to use a cataloged set of design structures known to be faulty and subsequently search for such faulty structures in a given design. Furthermore, the present approach supports a structured hierarchical design of the modeled system, as described herein. As described below with reference to the Fig. 2 and Fig. 3, the automated system 10 considered here pursues two main goals: (1) first to identify, catalog, and search for a design structure flowing from a given input data set, e.g., a state transition table, a state flow diagram, or a hierarchical state machine, and (2) to support a more structured hierarchical design in concrete / physical embodiments of the FSM-modeled system.

[0015] The Fig. The automated system 10 illustrated in Figure 1 may include a user device 12, e.g., a laptop computer, a tablet computer, a desktop computer, a mobile application (“app”), or other application-suitable host machine configured to assist the user 11 in designing a potentially complex hardware and / or software-based system. Although the user device 12 in Fig. 1 is illustrated as a single computing device for the sake of simplicity, those skilled in the art will understand that the user device 12 may be implemented as a distributed user device 120 having multiple processing nodes, e.g., 12A, 12B, ..., 12N, as shown in Fig. 1A is schematically illustrated. Such processing nodes may communicate with each other via suitable wired, wireless, and / or cloud-based network connections. Underlying systems that benefit from the automated system 10 may design human-machine interfaces ("HMIs") or other devices on board a motor vehicle or aircraft, a watercraft, a rail vehicle, or other dynamic system, or model the performance of a medical device, a jet engine, or other static system.

[0016] The Fig. The automated system 10 illustrated in Figure 1 may also include one or more peripheral devices 13, including a display screen 14 that serves as an output device for the user device 12. The user 11 may interact with the user device 12 via one or more additional peripheral devices 13 (not shown), such as a mouse, a keyboard, touch inputs on the display screen 14, etc., when developing or designing state transition tables for the FSM-modeled system, including the functions of the resident software and / or hardware thereof. The present solutions are intended to facilitate downstream verification of system behavior following the proper and thorough development of an FSM and the corresponding state transition table(s).Among the many potential benefits of the present solutions is that the user 11 is better able to identify within the larger design exactly where the design is not well structured and lacks an appropriate hierarchy.

[0017] As part of the present strategy, the user device 12 may Fig. 1 or the processing nodes 12A, 12B, ..., 12N forming it from Fig. 1A may be equipped with a non-volatile, tangible, computer-readable storage medium or memory (M) 54 and one or more processors (P) 56, e.g., logic circuits, combinational logic circuits, application-specific integrated circuits (ASICs), electronic circuits, central processing units, semiconductor integrated circuits, etc., as well as input / output (I / O) circuits, suitable signal conditioning and buffer circuits, and other components such as a high-speed clock to provide the described functionality. The associated memory 54 may comprise application-appropriate amounts and types of non-transitory memory, including read-only memory, programmable read-only memory, random access memory, hard disk, etc., whether resident or remote memory, or a combination of both.

[0018] Input data: As a precursor to the implementation of the 100M procedure of Fig. 3 receives the Fig. 1 receives system features 15 and user inputs 16 from the user 11, with the user inputs 16 populating the populated state transition table 20, thereby generating an updated version of the populated state transition table 20. That is, the state transition table is automatically populated according to the definitions of states, events, and super-events. The user 11 then enters the target states for each combination. This action could result in various states, state transitions, and events of the modeled system being received, along with possible "super-events" (event combinations), conditions (no response to traffic devices), hierarchy definitions, and other system features 15.

[0019] In response to the received system characteristics 15, the user device 12 automatically generates and outputs a first data set 17 containing an empty / unpopulated initial state transition table (Ti) 19. This initial state transition table 19 is indexed with the most complete possible population of possible states and events of the modeled system and with the system characteristics 15 entered by the user 11. Additionally, in some embodiments, the user device 12 automatically populates the initial state transition table 19 with a second data set 18 to generate a third data set 19S, wherein the third data set 19S contains a populated state transition table (“T P “) 20 contains.

[0020] That is, the user device 12 automatically generates (“autogenerates”) the populated state transition table 20 in response to the system characteristics 15 and other user inputs 16. After performing one or more iterations, the user device 12 finally outputs a final state transition table (T F ) 21. The final state transition table 21 may serve as data 110 associated with the design of the FSM-modeled system, the data 110 being used by a model verification platform 25 according to the disclosure. The data 110 is thus a starting point for further investigation by the user 11 when performing the method 100M of Fig. 3, if it verifies that the FSM-modeled system does not exhibit incorrect system behavior or does or does not exhibit other predetermined behavior as intended.

[0021] With reference to Fig. 2, the automated system 10 of Fig. 1 may involve an interaction between the user device 12 and the model verification platform 25. In general, the present approach involves receiving the data 110 associated with a system design, including the various states, state transitions, events, and outputs as mentioned above. The final state table 21 of Fig. 1 may be included with or fully embody the data 110. As contemplated herein, the model verification platform 25 may process and search / analyze the data 110, e.g., via a suitable search algorithm, to determine the presence of predetermined behavior and / or other desired properties.

[0022] The model verification platform 25 would then delineate, identify, or otherwise "label" the predetermined behavior as "verified behavior," where "verified" refers to a state after the identified behavior has been found. In response to the verified behavior, a control action may then be performed, as described below. For example, the target states S 1 , S 2 , S 3 and S 4 may be specified, possibly with problematic behavior or other properties such as undefined or ill-defined states or mode transitions, as shown. As part of the present method 100M of Fig. 3, the model verification platform 25 could then perform one or more control actions associated with marking the behavior, for example, by issuing a notification 160 to the user device 12 and / or an external device 22 as part of that action.

[0023] As mentioned below, the model verification platform 25 can be Fig. 1 and Fig. 2 transmit one or more notifications 160 as specific recommendations for correcting problematic behavior in the system design. For example, recommendations for correcting or better defining transitions between the target states S 1 , S 2 , S 3 and S 4be part of the notifications 160. As part of such an exchange, the user device 12 could receive the notification 160 and possibly provide recommendations to the user 11 in response to the notification 160. In some implementations, the model verification platform 25 may transmit information related to the identification and location of a problematic behavior or other characteristic that does not include recommendations for correction. In this way, the model verification platform 25 could be used to identify potential design flaws and provide recommendations / suggestions for correcting state tables or state flow diagrams, potentially saving computing resources (e.g., processors, memory, and / or the like) that might otherwise be wasted.The use of the model verification platform 25 thus facilitates the design of an FSM-modeled system, with the improved speed and efficiency of the design process and the quality of the designs being just some of the associated benefits.

[0024] In Fig. 3 is a logical flow diagram illustrating one embodiment of the present method 100M. The logical flow diagram is constructed from individual logical segments or blocks, with each block being implemented manually and / or automatically as needed, e.g., as one or more algorithms or code segments. Those skilled in the art will appreciate that the flow diagram may be Fig. 3 is also suitable for the implementation of individual hardware / software modules, each configured to perform the associated tasks. Therefore, the terms "block" and "module" are used synonymously below.

[0025] Blocks B101 (System Design Module) and B102 (Input Module) are incorporated into the method 100M and enable the user device 12 to Fig. 1, to receive data associated with the design of the FSM-modeled system ("System Design"). As provided herein, the system design module / Block B101 provides as complete a record as possible of the states, state transitions, events, and user-facing indications ("Outputs") of the FSM-modeled system. Block B101 is configured to create a usable system design for the FSM-modeled system. As is known in the art, this effort in turn includes generating and error-checking one or more state transition tables and / or transition diagrams, e.g., using the automated approach described in U.S. Patent Application No. 18 / 318,006, filed May 16, 2023, which is hereby incorporated by reference in its entirety, or using another sufficiently developed state transition table, e.g., the final state transition table 21 of Fig. 1. Such data is received in block B102 as inputs to the method 100M.

[0026] Block B103 (Correctness Properties Module) used by the Model Verification Platform 25 of Fig. 1, is configured to generate or construct a list of general system behavior, possibly in the form of subjective or objective "correctness properties." As contemplated herein, such a list of behavior could include desired system behavior, control inputs / outputs, cognitive actions of potential users of the FSM-modeled system, and / or the hierarchical structure of the various states, state transitions, events, and other data associated with the current system design. The list of correctness properties or other behaviors is then fed into a processing block B105 and its associated blocks B108, B110, and B112.

[0027] Block B104 (Hierarchy and Simplification Module) of Fig. 3 provides additional inputs to processing block B105. For example, block B104 could output a list of hierarchy and simplification properties ("H + S") for the FSM-modeled system in question. While such properties may vary depending on the application, relevant properties may include, for example, nesting properties that define grouped or related aspects of the defined properties, global events (as opposed to local or private events), consistency features such as shared definitions, and so on.

[0028] Block B105, in turn, comprises blocks B106, B108, and B110. In block B106 (search module A), the above-mentioned data is analyzed. For example, block B106 is configured to search the list of hierarchy and simplification properties from block B104 for the lack of a sufficient structural hierarchy, e.g., using a suitable search engine or algorithm as recognized in the art. The hierarchy and simplification properties are provided as state flow diagrams and / or transition tables, with this block ultimately analyzing the data for the lack of a sufficient structural hierarchy.Similarly, block B108 (search module B) could use the same or a different search algorithm to search the list of correctness properties (or other desired properties) from block B103 for erroneous or otherwise problematic behavior within the scope of the disclosure. Blocks B106 and B108 could then output their respective results to block B110 (ID and tagging module), with block B110 subsequently identifying problematic behavior based on the generated results.

[0029] Problematic behavioral characteristics: Objectively or subjectively "problematic" or undesirable behavioral characteristics are then output to block B112 for further action according to one non-limiting embodiment. This action may include flagging each problematic behavior and then performing one or more associated actions. For example, this action could include transmitting the notification 160 of the Fig. to the user device 12, wherein the notification 160 may include information related to the identification and location of the problematic behavior or other characteristics.

[0030] Block B112 (Design Proposal Module) of Fig. 3 could also include generating one or more recommendations for correcting the problematic behavior in this embodiment. Problematic behavior, as considered here, could include verification properties, structural hierarchy properties, and / or correctness properties. Verification properties within the scope of method 100M may include a set of predefined properties, wherein the user 11 of Fig. 1 can define the set of predefined properties. The set of predefined properties could be used to verify whether the predefined properties are present in the data 110 of Fig. 1 and Fig. 2 are present.

[0031] The presence or absence of one or more predefined properties in the set of predefined properties could represent a particular quality of the system design associated with the data. Examples of verification properties that subjectively "should" be present, e.g., at the user's discretion 11, could include clear hierarchical structures, the use of global events to reduce complexity, and the reduction of the number of events (i.e., private events). Similarly, examples of verification properties that "should not" exist could include design structures of the FSM-modeled system. The actual system could become unpredictable due to insufficient information and possibly overly complex behavior that the system designers did not foresee.Structural hierarchy properties could, in turn, include nesting, global events and event consistency, and inheritance of attributes (from parent to child).

[0032] Correctness properties: Within the framework of the 100M procedure of Fig. 3 Correctness properties may include, among other possible properties, desired system behavior properties, system control properties, and cognitive properties. System behavior properties are related to the behavior of a system and may include, for example, properties related to (1) non-determinism, (2) error state, (3) extending state, (4) restricting state, (5) extending actions, (6) delayed actions, and / or (7) intermittent event blocking.

[0033] Non-determinism: The non-deterministic nature of this property means that two or more different states have a behavioral manifestation. For example, different states, each representing a different attribute of automation behavior (e.g., driving on a highway versus driving on a traffic light-controlled route), automation behavior (e.g., escalation protocol), and automation / user control (e.g., lateral / longitudinal), may have a similar behavioral manifestation. Another example is the opening mechanism of a car door. Some vehicles have push buttons on the exterior door handle that are activated when the proximity of the key fob is detected. When activated, pressing this button unlocks the vehicle. However, the driver entering the vehicle does not know whether the button is activated or not (no light is illuminated).Because the detection mechanism isn't 100% reliable, sometimes the doors unlock when the button is pressed, and sometimes they don't. In other words, the automatic release event isn't triggered. The driver can't see all these internal state changes (activation, deactivation), so the system isn't deterministic from their perspective.

[0034] Error state: This next property represents a contradiction between the underlying behavioral model and the representational model communicated to the end user. That is, the actual behavioral (implementation) model is in one state while the representational model is in another. For example, the implementation model automatically transitions to a state that is not part of the representational model and is not indicated there.

[0035] Supplementary state: Following the example properties above, this additional property represents a situation in which the requirements demand that a certain state change is possible, but the behavioral (implementation) model does not have such a state.

[0036] Constraining state: The "constraining state" property used here represents a situation in which the representation model has no knowledge of events that can actually trigger state changes in the finite state machine. When the event occurs, the system's configuration changes without taking such a change into account.

[0037] Complementary actions: Within the framework of the 100M procedure of Fig. 3, this property represents situations where the user inputs of the FSM-modeled system conflict with automatic inputs. The conflicting actions can be categorized as assistive actions and opposing actions. An assistive action can occur when the automatic inputs reduce the user inputs, thereby conflicting with the amount of required user input. For example, a driver may turn the steering wheel of a vehicle in a certain direction. The automatic input turns the steering wheel in the same direction as the driver, thereby reducing the torque required by the driver to turn the steering wheel in the specific direction. This can become a problem if the automatic system stops operating, but the driver continues to apply the same torques as before.

[0038] An opposing action can occur in this example scenario when the automatic inputs are opposite to the user inputs. For example, a driver turns the steering wheel of a vehicle in a certain direction. The automatic input turns the steering wheel in the opposite direction of the driver, increasing the torque required by the driver to turn the steering wheel in the specific direction. The system control properties are in turn associated with system controls that affect the user inputs to the system, e.g., the opposing control. The opposing control considered here represents a situation in which the user inputs (e.g., steering wheel rotation) are opposed by automatic inputs (e.g., lane departure warning). The cognitive properties involved in performing method 100M of Fig. 3 are related to the logic of the FSM-modeled system.

[0039] Cognitive properties include, among others, (i) multiple states that have similar indications such as illuminated icons, LEDs, etc., but have dissimilar behavior (output). This could confuse a user of the physical system because the indications do not match the system behavior, (ii) multiple similar indications with a resulting possibility for a particular behavior that corresponds to only one of them (or not all of them), (iii) a single state (or set of states) with a corresponding integrated indication. The integrated indication consists of two or more values, each expressing a different property of the system. A user of a particular population segment where the indication is not easily distinguishable, e.g.a color-blind user may be insensitive to their format and not distinguish between them, (iv) a state with two indications (cases where the same state and the corresponding behavior are characterized by two different indications), and (v) two internal states with a visible indication that transition to two different control behaviors upon the same event (e.g., opposite control event in a lane keeping assistance system).

[0040] Further cognitive properties could be: (vi) two initial states and / or intermediate states with a visible display that transition to two final states with separate displays and different control behavior upon the same event, (vii) two initial states with a visible display that transition to two intermediate states with a visible display upon a first, identical event. The activation of a second, identical event transitions the intermediate states to two final states with separate displays and different control behavior (nondeterminism with possible delay), (viii) two initial states with separate displays that transition to two final states with separate displays upon the same event. This refers to cases where the same event (e.g., a similar key press) is used by many states of the system and leads to different outcomes depending on the initial states.What follows is a list of cognitive characteristics (see above) and a corresponding set of ways to deal with them.

[0041] The model verification platform 220 may generate one or more recommendations / suggestions for correcting one or more flagged problematic properties in a correction algorithm. The correction algorithm may generate one or more recommendations / suggestions based on the flagged problematic properties. The correction algorithm may provide the recommendations / suggestions based on the following non-limiting conditions: (i) two similar statements with corresponding, dissimilar meanings, e.g., a suggestion to change to a state statement may be made to user 11, (ii) multiple similar statements with a resulting enablement for a specific behavior that corresponds to only one of them (or not all), e.g.,propose to change a manifestation in the state that does not require that behavior, thus removing the enabling; (iii) a single state (or set of states) with a corresponding integrated indication. The integrated indication is composed of two or more values, each expressing a different property of the system. An end user of a particular demographic (e.g., color-blind vehicle drivers) may be insensitive to their format and therefore unable to distinguish between them.The user 11 could receive a suggestion or recommendation to add an additional display property to enable differentiation for possible end users with perceptual limitations, and (iv) a dual-display state (cases where the same state and the corresponding behavior are characterized by two different displays), which could result in the message 160 containing a recommendation to change a display property or to split the initial state into two meaningful states.

[0042] Further examples of cognitive properties in this sense are (v) two internal states with a visible display that transition into two different control behaviors upon the same event (e.g., opposite control event in a lane keeping assistance system). This could lead to the user 11 being recommended to change a state display, (vi) two initial and / or intermediate states with a visible display that transition into two final states with separate displays and different control behaviors upon the same event, for reasons of abstraction. Before a rare or unexpected state transition, a notification could be given explaining the reason for the unexpected transition, (vii) two initial states with a visible display that transition into two intermediate states with a visible display upon an initial, identical event.The activation of a second, identical event transforms the intermediate states into two final states with separate displays and different control behavior (non-determinism with possible delay).

[0043] In response, the notification 160 could state that a delayed state transition is imminent, as soon as the system can predict it, or (xiii) that two initial states with separate indications transition to two final states with separate indications at the same event. The use of local rules results in a high memory load for the end user. In this case, the model verification platform 25 could provide the notification 160 with subtle hints for the end user during the transition. The latter could also mean that the memory load of the user device 12 of the Fig. 1 and Fig. 2 is supported by subtle hints and simple notifications about the expected transition. If the event is a user-triggered event, the model verification platform 25 could help the user 11 determine when this behavior is unjustified.

[0044] The solutions of the present disclosure provide the user 11 of the Fig. 1 and Fig.2 therefore provides an improved data verification method that assists in the development and implementation of complex systems. Using the user device 12 and its programmed functionality, as described above, the user 11 is intuitively guided through the verification of system behavior and other predetermined properties. Such behavior could be problematic from the user 11's perspective, as mentioned above. Using this methodology, one could describe a system and subsequently verify the correctness of the design. Since the models are mathematical in nature, it is possible to verify them using computational power. Verification is performed by defining a set of structures or formal properties (both logical and cognitive, as described above) whose presence the user 11 wishes to ensure, e.g.Clear hierarchical structures and the use of global events to reduce complexity, or their absence, e.g., when the system becomes unpredictable to the user 11 due to insufficient information and perhaps due to overly complex behavior. These and other related advantages will be appreciated by those skilled in the art in light of the disclosure.

[0045] For the purposes of this description, the use of the singular includes the plural and vice versa, unless expressly excluded; the terms "and" and "or" apply both subjunctive and disjunctive; and the words "including," "containing," "comprising," "with," and the like mean "including without limitation." Furthermore, words of approximation such as "approximately," "almost," "substantially," "generally," "about," etc. may be used herein to mean "at, near, or almost at," or "within 0-5% of," or "within acceptable manufacturing tolerances," or logical combinations thereof. A component "configured" to perform a particular function is capable of performing the stated function without modification, rather than merely having the potential to perform the stated function after further modifications.In other words, if the hardware described is expressly configured to perform the specified function, it is specifically selected, created, implemented, used, programmed, and / or designed to perform the specified function.

[0046] The detailed description and the drawings or illustrations are supportive and descriptive of the present teachings, but the scope of the present teachings is defined solely by the claims. While some of the best modes and other embodiments for carrying out the present teachings have been described in detail, various alternative designs and embodiments for carrying out the present teachings exist, which are defined in the appended claims. Furthermore, this disclosure expressly includes combinations and subcombinations of the elements and features presented above and below. QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited patent literature

[0000] US 18 / 318,006

[0025]

Claims

[1] A model verification platform comprising: a system design module configured to receive from a user device data associated with a design of a system modeled with a finite state machine (FSM), the data describing states, state transitions, events, and outputs of the FSM-modeled system; a search module configured to search the data for a predetermined behavior of the FSM-modeled system, wherein the predetermined behavior comprises one or more predetermined state and / or mode changes of the FSM-modeled system; an identification / labeling module configured to label the predetermined behavior in a memory of the FSM-modeled system as a verified behavior; and a design suggestion module configured to perform a control action in response to the verified behavior, including transmitting a notification to the user device indicating the verified behavior. [2] The model verification platform of claim 1, wherein the system design module is configured to receive the data as a state transition table. [3] The model verification platform of claim 1, wherein the system design module is configured to receive the data as a state flow diagram. [4] The model verification platform of claim 1, wherein the verified behavior includes a problematic behavior, and wherein the design suggestion module is configured to transmit the notification as information associated with a position of the problematic behavior within the data. [5] The model verification platform of claim 4, wherein the design suggestion module is configured to automatically generate one or more recommendations for correcting the problematic behavior, and wherein the notification includes the one or more recommendations. [6] The model verification platform of claim 1, wherein the predetermined behavior includes structural hierarchy properties. [7] The model verification platform of claim 6, wherein the structural hierarchy properties comprise nesting, global events and / or event consistency properties. [8] The model verification platform of claim 1, wherein the predetermined behavior includes correctness properties, the correctness properties comprising system behavior properties, system control properties, and / or cognitive properties. [9] The model verification platform of claim 1, wherein the predetermined behavior of the FSM-modeled system includes non-deterministic system behavior properties representing two or more different states having a behavioral manifestation. [10] A non-transitory, computer-readable storage medium having recorded thereon computer-readable instructions that, when executed by one or more processors of a model verification platform, cause the one or more processors to: receive from a user device data associated with a design of a system modeled with a finite state machine (FSM), the data describing states, state transitions, events, and outputs of the FSM-modeled system, the data including a state transition table or a state flow diagram; Searching the data via the model verification platform for a predetermined behavior of the FSM-modeled system, wherein the predetermined behavior comprises one or more predetermined state and / or mode changes of the FSM-modeled system; Marking the predetermined behavior as verified behavior; and Performing a control action in response to the verified behavior, including transmitting a notification to the user device indicating the verified behavior and containing recommendations for correcting at least part of the verified behavior.

Images