Behavior verification for finite state machine modeling systems

Abstract

And carrying out behavior verification on the finite-state machine modeling system. A method or any other representative method for verifying system behavior and correcting design defects in a finite state machine (FSM) modeling system includes receiving data associated with a system design from a user device via a model verification platform. The data describes states, state transitions, events, and outputs of the FSM modeling system. The method includes searching the data for predetermined behaviors of the FSM modeling system, the predetermined behaviors including predetermined state and / or mode change (s). The method includes marking the predetermined behavior as a validated behavior, and performing a control action in response to the validated behavior, including transmitting a notification to the user device, the notification indicating the validated behavior and a design recommendation when applicable. Instructions for the method may be recorded in a computer readable storage medium and executed by a processor to cause a model verification platform to execute the method.

Description

[0001] introduction

[0002] The present disclosure relates to a software-based support "toolbox" for assisting the design and implementation of a finite state machine (FSM) modeling system having multiple states, state transitions / mode changes, and other potentially complex behaviors. The present method is intended to assist system designers, programmers, and other users during the system design process by identifying potential design flaws and providing corrective recommendations as needed. In addition to behavioral aspects such as state or mode transitions, other traits considered herein may include interface indications (icons, telltales, light bars, etc.), interaction schemes (buttons, levelers, etc.), alerts and warnings, overall behaviors and conditions (responses to traffic control devices or their absence), and escalation protocols for automated vehicle behavior (e.g., minimum risk maneuvers (MRMs) while driving and minimum risk conditions (MRCs) such as stopping on the shoulder).

[0003] As understood in the art, finite state machines are mathematical abstractions frequently used to design and verify the behavior of countless different software programs and physical systems. Finite state machines can be graphically represented as state flow diagrams, state transition tables, or hierarchical state machines / diagrams such as state diagrams. The FSM modeling system starts from an initial state. Based on the current state of the designed system and a given single event or combination of events ("super events"), the finite state machine can switch between various additional states in response to system inputs or triggering events. Although the above-mentioned state transition tables or state flow diagrams widely used and understood in the prior art contribute to the overall system design process, the resulting system design may still exhibit suboptimal or incorrect design structures and behaviors. Summary of the invention

[0004] An automated system and associated methods are disclosed herein for assisting a user (e.g., a software programmer, designer, or system developer) in verifying the system behavior of a finite state machine (FSM) modeling system. The automated methods contemplated herein are particularly useful for designing systems with relatively complex and / or highly interactive behavioral traits, such as a wide range of possible states, state transitions, state or mode triggering events, and outputs. For example, a motor vehicle with automated control capabilities has relatively complex operating modes and state transition rules. Some of these modes are executed automatically / autonomously or in response to driver input, while other modes may be based on timers, hidden logic, or other automatically occurring activation criteria. Other complex systems (such as avionics, process control automation, medical equipment, and associated control logic for a wide range of mobile or stationary systems) are designed using finite state machine technology and will similarly benefit from automated verification methods as described in detail below.

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

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

[0007] The verified behavior may include problematic behavior, in which case the notification includes information associated with the location of the problematic behavior within the data. Performing a control action may include automatically generating one or more recommendations for correcting the problematic behavior.

[0008] The predetermined behavior according to one or more embodiments includes a structural hierarchy property. For example, the structural hierarchy property may include 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. In some implementations, the predetermined behavior of the FSM modeling system includes a non-deterministic system behavior property representing two or more different states with a behavioral manifestation.

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

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

[0011] This application provides the following technical solutions:

[0012] 1. A method for verifying the behavior of a finite state machine (FSM) modeling system, comprising:

[0013] receiving data associated with a design of a FSM modeling system from a user device via a model verification platform, wherein the data describes states, state transitions, events, and outputs of the FSM modeling system;

[0014] searching the data via the model verification platform for predetermined behavior properties of the FSM modeling system, the predetermined behavior comprising one or more predetermined states and / or mode changes of the FSM modeling system;

[0015] Marking the predetermined behavior in the memory of the model verification platform as a verified behavior; and

[0016] A control action is performed in response to the verified behavior, including transmitting a notification to a user device indicating the verified behavior.

[0017] 2. The method according to technical solution 1, wherein receiving data associated with the design of the FSM modeling system includes receiving a state transition table.

[0018] 3. The method according to technical solution 1, wherein receiving data associated with the design of the FSM modeling system includes receiving a state flow diagram.

[0019] 4. A method according to technical solution 1, wherein the verified behavior includes problematic behavior, and wherein the notification includes information associated with the location of the problematic behavior within the data.

[0020] 5. The method according to technical solution 4, wherein executing the control action includes automatically generating one or more recommendations for correcting problematic behaviors.

[0021] 6. A method according to technical solution 1, wherein the predetermined behavior includes structural hierarchical properties.

[0022] 7. A method according to technical solution 6, wherein the structural hierarchy properties include nesting, global events and / or event consistency properties.

[0023] 8. A method according to technical solution 1, wherein the predetermined behavior includes a correctness property.

[0024] 9. A method according to technical solution 8, wherein the correctness properties include system behavior properties, system control properties and / or cognitive properties.

[0025] 10. The method according to technical solution 1, wherein the predetermined behavior of the FSM modeling system includes a non-deterministic system behavior property representing two or more different states with a behavioral performance.

[0026] 11. A model verification platform, comprising:

[0027] a system design module configured to receive data associated with a design of a finite state machine (FSM) modeling system from a user device, wherein the data describes states, state transitions, events, and outputs of the FSM modeling system;

[0028] a search module configured to search the data for predetermined behavior of the FSM modeling system, the predetermined behavior comprising one or more predetermined states and / or mode changes of the FSM modeling system;

[0029] an identification / marking module configured to mark the predetermined behavior in a memory of the FSM modeling system as a verified behavior; and

[0030] A design suggestion module is configured to perform a control action in response to the verified behavior, including transmitting a notification indicating the verified behavior to a user device.

[0031] 12. A model verification platform according to technical solution 11, wherein the system design module is configured to receive the data as a state transition table.

[0032] 13. A model verification platform according to technical solution 11, wherein the system design module is configured to receive the data as a state flow diagram.

[0033] 14. A model verification platform according to technical solution 11, wherein the verified behavior includes problematic behavior, and wherein the design suggestion module is configured to transmit the notification as information associated with the location of the problematic behavior within the data.

[0034] 15. A model verification platform according to technical solution 14, wherein the design suggestion module is configured to automatically generate one or more recommendations for correcting problematic behaviors, and wherein the notification includes the one or more recommendations.

[0035] 16. A model verification platform according to technical solution 11, wherein the predetermined behavior includes structural hierarchical properties.

[0036] 17. A model verification platform according to technical solution 16, wherein the structural hierarchy properties include nesting, global events and / or event consistency properties.

[0037] 18. A model verification platform according to technical solution 11, wherein the predetermined behavior includes correctness properties, and the correctness properties include system behavior properties, system control properties and / or cognitive properties.

[0038] 19. A model verification platform according to technical solution 11, wherein the predetermined behavior of the FSM modeling system includes non-deterministic system behavior properties representing two or more different states with a behavioral performance.

[0039] 20. A non-transitory computer-readable storage medium having computer-readable instructions recorded thereon, the computer-readable instructions, when executed by one or more processors of a model verification platform, causing the one or more processors to:

[0040] receiving data associated with a design of a finite state machine (FSM) modeling system from a user device, wherein the data describes states, state transitions, events, and outputs of the FSM modeling system, the data comprising a state transition table or a state flow diagram;

[0041] searching the data via the model verification platform for predetermined behavior of the FSM modeling system, the predetermined behavior comprising one or more predetermined states and / or mode changes of the FSM modeling system;

[0042] marking the predetermined behavior as a verified behavior; and

[0043] A control action is performed in response to the verified behavior, including transmitting a notification to a user device, the notification indicating the verified behavior and including a recommendation for correcting at least some of the verified behavior.

[0044] The above-mentioned features and advantages of the present disclosure and other features and attendant advantages will be readily apparent from the following detailed description of illustrative examples and modes for carrying out the present disclosure when taken in conjunction with the accompanying drawings and the appended claims. In addition, the present disclosure expressly includes combinations and sub-combinations of the elements and features presented above and below. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] The accompanying drawings, which are incorporated into and constitute a part of this specification, illustrate the implementation of the present disclosure and are used together with the description to explain the principles of the present disclosure. The accompanying drawings are not necessarily to scale and may present slightly simplified representations of various preferred features of the present disclosure as disclosed herein, including, for example, specific dimensions, orientations, positions, and shapes. The details associated with such features will be determined in part by the specific intended application and use environment.

[0046] Figure 1 An automation system for use in designing and implementing a system using finite state machine (FSM) based design techniques according to the present disclosure is illustrated, wherein the automation system is configured to verify and help correct the behavior of the designed system.

[0047] Figure 1A The diagram shows the Figure 1 An exemplary embodiment of a distributed processing node is used when using a portion of an automation system.

[0048] Figure 2 A behavior verification method according to the present disclosure is illustrated.

[0049] Figure 3 is a flow chart of a method for verifying system behavior according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0050] The present disclosure can be embodied in many different forms. Representative examples of the present disclosure are shown in the accompanying drawings and described in detail herein as non-limiting examples of the disclosed principles. For this reason, elements and limitations described in the abstract, introduction, title, and detailed description but not explicitly stated in the claims should not be incorporated into the claims individually or collectively by implication, inference, or otherwise.

[0051] Referring to the drawings, wherein like reference numerals refer to like features throughout the several views, Figure 1 An automated system 10 configured to verify the behavior of a finite state machine (FSM) modeled system is depicted. Due to the importance of achieving as close to perfect an understanding and implementation of the designed system as possible during the design process, and in order to develop a system without incorrect structures that may lead to design errors and incorrect user interactions, it is useful to verify that the designed system and associated human-machine interfaces will behave in a logical manner and also that their behavior is as intended by a user 11, such as a designer or programmer, rather than a driver, pilot, or other end user of a physical embodiment of the modeled system.

[0052] To this end, the present solution makes it possible for the user 11 to employ a catalog of known incorrect design structures and thereafter search for such incorrect structures in a given design. Additionally, the present method supports the structured hierarchical design of the modeling system as set forth herein. Figure 2 and Figure 3 As described in detail, the automation system 10 as considered herein has two main goals: (1) initially identifying, cataloging, and searching for design structures, such as state transition tables, state flow diagrams, or hierarchical state machines, from a given input data set; and (2) supporting a more structured hierarchical design in a tangible / physical embodiment of a FSM modeling system.

[0053] Figure 1 The automation system 10 illustrated in FIG. 1 may include a user device 12, such as a laptop computer, tablet computer, desktop computer, mobile application (“app”), or another suitable host computer configured to assist a user 11 in the design of a potentially complex hardware and / or software-based system. Although for simplicity of illustration, the user device 12 is not shown in FIG. Figure 1 Although depicted as a single computer device in FIG. 1 , those skilled in the art will appreciate that the user device 12 may be implemented as a distributed user device 120 having multiple processing nodes (eg, 12A, 12B, ..., 12N), such as Figure 1ASuch processing nodes may communicate with each other via suitable wired, wireless and / or cloud-based networking connections. The underlying systems that benefit from the automation system 10 are used to design human-machine interfaces (“HMIs”) or other equipment on motor vehicles or aircraft, ships, rail vehicles or other dynamic systems, or to model the performance of medical devices, power plants or other static systems.

[0054] Figure 1 The automation system 10 illustrated in the figure may also include one or more peripheral devices 13, including a display screen 14 that can operate as an output device of the user device 12. When developing or designing state transition tables for the FSM modeling system, including the functionality of the resident software and / or its hardware, the user 11 can interact with the user device 12 via one or more additional peripheral devices 13 (not shown), such as a mouse, keyboard, touch input of the display screen 14, etc. The present solution is intended to facilitate downstream verification of system behavior after the correct and thorough design of the FSM and the corresponding (one or more) state transition tables. Among the many possible incidental benefits of the present solution, the user 11 is better able to accurately identify where the design is not well structured and lacks sufficient levels in a larger design.

[0055] As part of this strategy, Figure 1 User equipment 12 or Figure 1A Its constituent processing nodes 12A, 12B, ..., 12N may be equipped with non-transitory tangible computer-readable storage media or memory (M) 54 and one or more processors (P) 56, such as logic circuits, (one or more) combinational logic circuits, (one or more) application-specific integrated circuits (ASICs), (one or more) electronic circuits, (one or more) central processing units, semiconductor IC devices, etc., and (one or more) input / output (I / O) circuits, appropriate signal conditioning and buffering circuits, and other components such as high-speed clocks, to provide the described functions. The associated memory 54 may include a quantity and type of non-transitory memory suitable for the application, including read-only, programmable read-only, random access, hard disk drives, etc., whether resident, remote, or a combination of both.

[0056] Input data: As execution Figure 3 The method has a 100M predecessor. Figure 1The user device 12 illustrated in FIG. 1 receives system characteristics 15 and user input 16 from the user 11, wherein the user input 16 is filled in 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 following the definition of states, events, and super events. The user 11 then enters the destination state for each combination. This action may require receiving various states, state transitions, and events of the modeled system, along with possible "super events" (event combinations), conditions (no response to traffic devices), hierarchy definitions, and other system characteristics 15.

[0057] In response to the received system characteristics 15, the user device 12 automatically generates and outputs a first data set 17, which embodies a blank / unpopulated initial state transition table ("T"). The initial state transition table 19 is indexed by a population of possible states and events of the modeled system and by 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 the second data set 18 to generate a third data set 19S, wherein the third data set 19S includes the populated state transition table ("T P ”)20.

[0058] That is, the user device 12 automatically generates ("auto-generates") 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 ultimately outputs the final state transition table (T F ) 21. The final state transition table 21 can be used as data 110 associated with the design of the FSM modeling system, wherein the data 110 is used by the model verification platform 25 according to the present disclosure. Therefore, when verifying that the FSM modeling system does not exhibit incorrect system behavior, or exhibits or lacks other predetermined behaviors as expected, the data 110 is executed. Figure 3 The method 100M was the starting point for further investigation by user 11.

[0059] Brief reference Figure 2 , Figure 1 The automated system 10 may involve interaction of a user device 12 and a model validation platform 25. In general, the method involves receiving data 110 associated with a system design, including various states, state transitions, events, and outputs as described above. Figure 1 The final state table 21 may be included in the data 110 or fully embodies the data 110. As contemplated herein, the model validation platform 25 may process and search / analyze the data 110, for example, via a suitable search algorithm, for the presence of predetermined behaviors and / or other desired properties.

[0060] Thereafter, the model verification platform 25 will classify, identify, or otherwise "mark" the predetermined behavior as a "verified behavior," where "verified" refers to the post-search state of the marked behavior. Control actions can then be performed in response to the verified behavior, as described below. For example, nominal states S1, S2, S3, and S4 can be specified in the data 110, potentially having problematic behaviors or other properties, such as undefined or poorly defined states or mode transitions, as shown. As Figure 3 As part of the present method 100M, the model validation platform 25 may thereafter perform one or more control actions associated with flagging the behavior, such as by outputting a notification 160 to the user device 12 and / or the external device 22 as part of the action.

[0061] As described below, Figure 1 and Figure 2 The model verification platform 25 can 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 nominal states S1, S2, S3, and S4 can be part of the notifications 160. As part of such an exchange, the user device 12 can receive the notifications 160 and may provide recommendations to the user 11 in response to the notifications 160. In some implementations, the model verification platform 25 can transmit information associated with the identification and location of problematic behavior or other properties that does not include recommendations for correction. In this way, the model verification platform 25 can be used to identify potential design flaws and provide recommendations / suggestions for correcting state tables or state flow diagrams, and may save computing resources (e.g., processors, memory, and / or the like) that would otherwise be wasted. Therefore, the use of the model verification platform 25 facilitates the design of FSM modeling systems, where the improved speed and efficiency of the design process and the quality of the design are just some of the incidental benefits.

[0062] Reference now Figure 3 , shows a logic flow diagram illustrating an embodiment of the present method 100M. The logic flow diagram is constructed from constituent logic segments or blocks, wherein each block is implemented manually and / or automatically as required, for example as one or more algorithms or code segments. Those skilled in the art will appreciate that Figure 3 The flowchart also lends itself to the implementation of constituent hardware / software modules, each of which is configured to perform associated tasks. Therefore, the terms "block" and "module" are used synonymously hereinafter.

[0063] Block B101 (system design module) and block B102 (input module) feed into method 100M and together make Figure 1 The user device 12 is capable of receiving data associated with the design of the FSM modeling system ("system design"). As considered herein, the system design module / block B101 provides as complete a record as possible of the states, state transitions, events, and user-oriented instructions ("outputs") of the FSM modeling system. Block B101 is configured to construct a feasible system design for the FSM modeling system. As understood in the art, this effort, in turn, involves the generation and error checking of one or more state transition tables and / or transition diagrams, such as using the automated methods described in U.S. patent application serial number 18 / 318,006 filed on May 16, 2023, which is incorporated herein by reference in its entirety, or using another fully developed state transition table, such as Figure 1 Final state transition table 21. Such data is received at block B102 as input to method 100M.

[0064] Can be Figure 1 Block B103 (Correctness Property Module) executed by or forming part of the model verification platform 25 of the FSM is configured to generate or construct a list of common system behaviors, possibly in the form of subjective or objective "correctness" properties. As contemplated herein, such a list of behaviors may include expected system behaviors, control inputs / outputs, cognitive actions of potential users of the FSM modeling system, and / or a hierarchy of 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 the processing block B105 and its resident blocks B108, B110, and B112.

[0065] Figure 3 Block B104 (Hierarchy and Simplification Module) of the FSM modeling system provides additional input to processing block B105. For example, block B104 may output a list of hierarchy and simplification ("H+S") properties of the FSM modeling system in question. While such properties may vary with the intended application, relevant properties may include, for example, nested properties that define groupings or related aspects of defined properties, global events (as opposed to local or private events), consistency features such as public definitions, etc.

[0066] Block B105 itself includes constituent blocks B106, B108, and B110. At block B106 (search module A), the above data is analyzed, for example, block B106 is configured to search for a list of hierarchical and simplified properties from block B104 for lack of sufficient structural levels, for example, using a suitable search engine or algorithm as understood in the art. The hierarchical and simplified properties are made available as state flow diagrams and / or transition tables, where the block ultimately analyzes the data for lack of sufficient structural levels. Similarly, block B108 (search module B) can use the same or another search algorithm to search for a list of correctness properties (or other desired properties) from block B103 for incorrect or otherwise problematic behaviors within the scope of the present disclosure. Then, blocks B106 and B108 can output their corresponding results to block B110 (ID and tag module), where block B110 thereafter identifies problematic behaviors from the generated results.

[0067] Problematic Behavior Properties: Then, according to a non-limiting embodiment, objectively or subjectively "problematic" or undesirable behavior properties are output to block B112 for further action. The action may include marking each problematic behavior and thereafter performing one or more actions associated therewith. As an example, the action may include transmitting to the user device 12 Figure 1 and 2 Notification 160 of the invention may include information associated with the identity and location of the problematic behavior or other nature.

[0068] In this embodiment, Figure 3 Block B112 (design suggestion module) of method 100M may also include generating one or more recommendations for correcting problematic behaviors. Problematic behaviors as considered herein may 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 Figure 1 The user 11 can define the set of predefined properties. The set of predefined properties can be used to verify whether the predefined properties exist. Figure 1 and 2 The data is 110.

[0069] The presence or absence of one or more predefined properties in the set of predefined properties can represent a particular quality of the system design associated with the data. Examples of validation properties that subjectively "should" exist (e.g., according to the judgment of user 11) can include a clear hierarchy, the use of global events to reduce complexity, and a reduction in the number of events (i.e., private events). Similarly, examples of validation properties that "should not" exist can include the design structure of a FSM modeling system. Actual systems can become unpredictable due to bad indications and perhaps overly complex behaviors that the system designer may not have anticipated. Structural hierarchical properties for their parts can include nesting, global events and event consistency, and inheritance of attributes (from parent to child).

[0070] Correctness property: Figure 3 Within the scope of method 100M, correctness properties may include, among other possible properties, desired system behavior properties, system control properties, and cognitive properties. System behavior properties are associated with the behavior of the system and may include, for example, properties related to: (1) non-determinism, (2) error states, (3) augmenting states, (4) limiting states, (5) augmenting actions, (6) delayed actions, and / or (7) intermittent event blocking.

[0071] Non-determinism: The non-deterministic nature of this property represents two or more different states with one behavior. For example, the following situation, where different states - each state represents different automation behavior attributes (e.g., driving on a highway vs. driving on a route full of traffic lights), automation behavior (e.g., upgrade protocol), and automation / user control (e.g., lateral / longitudinal) - may have similar behavior. Another example is a door opening mechanism. Some vehicles have a button on the outside door handle that becomes enabled when a remote control key is detected approaching. When enabled, pressing the button unlocks the vehicle. However, the driver entering the vehicle does not know when the button is enabled or not enabled (no light is provided). Because the detection mechanism is not 100% reliable, sometimes pressing the button unlocks the door, and sometimes it does not. In other words, the event automatic enablement is not initiated. The driver cannot see all these internal (enable, disable) state changes, and therefore from their perspective, the system is non-deterministic.

[0072] Error state: The next property indicates a contradiction between the underlying behavioral model and the presentation model delivered to the end user. That is, the actual behavioral (implementation) model is in one state and the presentation model is in another state. For example, the implementation model automatically transitions to a state that is not part of the presentation model and is not alluded to there.

[0073] Augmented State: Continuing with the above exemplary property, this additional property represents the situation where a requirement requires that a certain state change is possible, but the behavioral (implementation) model does not have such a state.

[0074] Limit state: As used herein, the "limit state" property refers to a situation in which the representation model ignores an event (or events) that can in fact trigger a state change in the finite state machine. When the event occurs, the configuration of the system changes without taking into account such a change.

[0075] Extension action: Figure 3 Within the scope of method 100M, this property represents a situation where input from a user of the FSM modeling system conflicts with automated input. Conflicting actions can be categorized into auxiliary actions and opposite actions. An auxiliary action can occur when an automated input reduces a user input, thereby conflicting with the amount of required user input. For example, a driver may turn the steering wheel of a vehicle in a particular direction. The automated input also turns the steering wheel in the same direction as the driver, thereby reducing the amount of torque required by the driver to turn the steering wheel in the particular direction. This can be a problem when the automated device stops its action, but the driver applies the same torque input as before.

[0076] In this example scenario, an opposing action may occur when the automatic input is opposite to the user input. For example, the driver turns the steering wheel of the vehicle in a particular direction. The automatic input turns the steering wheel in the opposite direction of the driver; thereby increasing the amount of torque required by the driver to turn the steering wheel in the particular direction. The system control property is itself associated with system controls (e.g., opposing controls) that affect user inputs into the system. Opposing controls as considered herein represent situations where the user input (e.g., steering wheel rotation) is opposite to the automatic input (e.g., lane keeping assist). In performing Figure 3 The cognitive properties of the method 100M process are considered in conjunction with the logic of the FSM modeling system.

[0077] Cognitive properties may include, but are not limited to, for example (i) multiple states that share a similar set of indications (such as illuminated icons, LEDs) but have dissimilar behaviors (outputs). This may confuse users of the physical system because the indications are inconsistent with the system behavior; (ii) multiple similar indications with an affordance for a behavior that corresponds to only one of them (or not all of them); (iii) a single state (or a set of states) with a corresponding integrated indication. The integrated indication consists of two or more values, each expressing a different characteristic of the system. Users of a certain group segment where the indication is not easily distinguishable by the group segment (e.g., color blind users) may be insensitive to their format and will fail to distinguish them; (iv) a state with two indications (a situation where the same state and corresponding behavior are labeled by two different indications); and (v) two internal states with one visual indication that translates into two different control behaviors on the same event (e.g., opposite control events in a lane keeping assist system).

[0078] Continuing with this discussion, additional cognitive properties may include: (vi) two initial and / or intermediate states with a visual indication that transforms upon the same event into two end states with separate indications and different control behaviors; (vii) two initial states with a visual indication that transforms upon the first same event into two intermediate states with a visual indication. Activation of the second same event transforms the intermediate state into two end states with separate indications and different control behaviors (with potential delayed non-determinism); (viii) two initial states with separate indications that transform upon the same event into two end states with separate indications. This refers to situations where the same event (e.g., a similar button press) is used by many states of the system and produces different results depending on the original state. What follows is a list of cognitive properties (above) and a corresponding set of ways to handle them.

[0079] The model verification platform 220 can generate one or more recommendations / suggestions for correcting one or more marked problematic properties in the correction algorithm. The correction algorithm can generate one or more recommendations / suggestions based on the marked problematic properties. The correction algorithm can provide recommendations / suggestions based on the following non-limiting conditions: (i) two similar indications, which have corresponding non-similar meanings, for example, a suggestion to change to a state indication can be provided to the user 11; (ii) multiple similar indications, which have a resulting revelation for a certain behavior, which corresponds to only one of them (or not all of them), for example, the following suggestion can be provided to the user 11: change the performance in a state where the behavior is not required so that the revelation is cancelled; (iii) a single state (or a group of states) with a corresponding integrated indication. The integrated indication consists of two or more values, each expressing a different characteristic of the system. End users of a certain group segment (e.g., color-blind drivers of vehicles) may be insensitive to their format and therefore fail to distinguish them. A suggestion or recommendation may be provided to user 11 to add additional indicative properties so that the separation is distinguishable to an eventual end user with a perceptual impairment; and (iv) a state having two indications (a situation where the same state and corresponding behavior are labeled by two different indications), which may result in notification 160 including a recommendation to change the indicative properties, or to split the initial state into two meaningful states.

[0080] Still other examples of cognitive properties in this regard include: (v) two internal states with one visual indication that transition to two different control behaviors on the same event (e.g., opposite control events in a lane keeping assist system). This may result in a recommendation to the user 11 to change a state indication; (vi) two initial and / or intermediate states with one visual indication that, for abstract reasons, transition to two final states with separate indications and different control behaviors on the same event. Notifications may be provided prior to rare or unexpected state transitions, with an explanation of the reasons for the unexpected transitions; (vii) two initial states with one visual indication that transition to two intermediate states with one visual indication on the first identical event. Activation of a second identical event transitions the intermediate state to two final states with separate indications and different control behaviors (with potential delayed non-determinism).

[0081] In response, notification 160 may be: a delayed state transition is about to occur (once the system can predict this), or (xiii) two initial states, with separate indications, that transition to two final states with separate indications on the same event. Using local rules imposes a high memory load on the end user, in which case the model verification platform 25 may provide notification 160 that presents a subtle cue to the end user in the event of the transition. This latter action may also need to be supported with a subtle cue along the way of a simple notification about the expected transition. Figure 1 and 2 The memory load of the user device 12. If the event is a user-initiated event, the model verification platform 25 can help the user 11 determine when the behavior is not warranted.

[0082] Therefore, the solution of the present disclosure is to Figure 1 and Figure 2 The user 11 is provided with an improved data verification method that assists in the design and implementation of complex systems. Using the user device 12 and its programming functions as described above, the user 11 is intuitively guided through the verification of system behavior and other predetermined properties. As described above, such behavior may be problematic from the perspective of the user 11. Using this method, the system can be described and its design correctness can be verified thereafter. Since the models are mathematical in nature, it is possible to verify them using computing power. Verification is accomplished by defining a set of structural or formal properties (both logical properties and cognitive properties discussed above) that the user 11 wishes to ensure exists (e.g., a clear hierarchy and a user of global events that reduce complexity) or does not exist (e.g., where the system becomes unpredictable to the user 11 due to poor indications, and perhaps due to overly complex behavior). In view of the present disclosure, those skilled in the art will understand these and other attendant benefits.

[0083] For the purposes of this specification, unless otherwise stated, the use of the singular includes the plural, and vice versa, the terms "and" and "or" shall be both conjunctions and disjunctions, and the words "include", "comprise", "includes", "have", and the like shall mean "including but not limited to". In addition, approximate words such as "about", "almost", "substantially", "generally", "approximately", etc. may be used herein in the sense of "at, close to, or nearly at", or "within 0-5% of", or "within an acceptable manufacturing tolerance", or a logical combination thereof. As used herein, a component that is "configured to" perform a specified function is capable of performing the specified function without change, rather than merely having the potential to perform the specified function after further modification. In other words, the described hardware, when explicitly configured to perform a specified function, is specifically selected, created, implemented, utilized, programmed, and / or designed for the purpose of performing the specified function.

[0084] The detailed description and the accompanying drawings or figures are support and description of the present teaching, but the scope of the present teaching is limited only by the claims. Although the best mode and some of the other embodiments for carrying out the present teaching have been described in detail, there are various alternative designs and embodiments for implementing the present teaching defined in the appended claims. In addition, the present disclosure explicitly includes combinations and sub-combinations of the elements and features presented above and below.

Claims

1. A model verification platform, comprising: a system design module configured to receive data associated with a design of a finite state machine (FSM) modeling system from a user device, wherein the data describes states, state transitions, events, and outputs of the FSM modeling system; a search module configured to search the data for predetermined behavior of the FSM modeling system, the predetermined behavior comprising one or more predetermined states and / or mode changes of the FSM modeling system; an identification / marking module configured to mark the predetermined behavior in the memory of the FSM modeling system as a verified behavior; as well as A design suggestion module is configured to perform a control action in response to the verified behavior, including transmitting a notification indicating the verified behavior to a user device. 2 . The model verification platform according to claim 1 , wherein the system design module is configured to receive the data as a state transition table. 3 . The model validation platform of claim 1 , wherein the system design module is configured to receive the data as a state flow diagram. 4 . The model validation platform of claim 1 , wherein the validated behavior comprises problematic behavior, and wherein the design suggestion module is configured to transmit the notification as information associated with a location of the problematic behavior within the data. 5 . The model validation platform of claim 4 , wherein the design suggestion module is configured to automatically generate one or more recommendations for correcting problematic behavior, and wherein the notification includes the one or more recommendations. The model validation platform according to claim 1 , wherein the predetermined behavior comprises a structural hierarchical property. 7 . The model verification platform according to claim 6 , wherein the structural hierarchy properties include nesting, global events and / or event consistency properties. 8 . The model verification platform according to claim 1 , wherein the predetermined behavior comprises a correctness property, and the correctness property comprises a system behavior property, a system control property and / or a cognitive property. 9 . The model verification platform according to claim 1 , wherein the predetermined behavior of the FSM modeling system includes a non-deterministic system behavior property representing two or more different states having a behavior performance.

10. A non-transitory computer-readable storage medium having computer-readable instructions recorded thereon, the computer-readable instructions, when executed by one or more processors of a model verification platform, causing the one or more processors to: receiving data associated with a design of a finite state machine (FSM) modeling system from a user device, wherein the data describes states, state transitions, events, and outputs of the FSM modeling system, the data comprising a state transition table or a state flow diagram; searching the data via the model verification platform for predetermined behavior of the FSM modeling system, the predetermined behavior comprising one or more predetermined states and / or mode changes of the FSM modeling system; marking the predetermined behavior as a verified behavior; as well as A control action is performed in response to the verified behavior, including transmitting a notification to a user device, the notification indicating the verified behavior and including a recommendation for correcting at least some of the verified behavior.

Images