Embedded software model architecture, battery management system controller and vehicle

Abstract

A software model architecture and a battery management system controller and a vehicle having the software model architecture. The software model architecture includes: a timing control unit and at least one functional unit; the timing control unit is used to receive an input signal and output a state quantity signal to the functional unit according to the input signal, the state quantity signal is used to trigger at least one of the functional units to execute a corresponding control logic and control the execution order of the control logic of at least one of the functional units; at least one of the functional units is used to receive the state quantity signal and execute the corresponding control logic according to the state quantity signal. In this way, the timing between the units can be coordinated in an orderly manner to ensure the overall stable and accurate operation of the model.

Description

Technical Field

[0001] The present application relates to the technical field of software model design, and more specifically, to an embedded software model architecture, a battery management system controller and a vehicle. Background Art

[0002] The embedded software model architecture is used in many scenarios because of its strong model visualization, easy maintenance, automatic code generation, and suitability for writing complex logic.

[0003] The current embedded software model architecture mainly includes several units, each of which has independent functions and executes different logics. Models with different strategies have different operating timings. Each unit is independent of each other and the timings do not affect each other. If you want to control the operating timing of the entire model, you need to coordinate the timings between the units to effectively cooperate so that the model as a whole can operate effectively. Summary of the invention

[0004] One purpose of the present application is to provide a new technical solution for an embedded software model architecture, a battery management system controller and a vehicle, which can coordinate the timing between the units in an orderly manner to ensure the overall stable and accurate operation of the model.

[0005] According to the first aspect of the present application, an embedded software model architecture is provided, comprising: a timing control unit and at least one functional unit; the timing control unit is used to receive an input signal, and output a state quantity signal to the functional unit according to the input signal, the state quantity signal is used to trigger at least one of the functional units to execute corresponding control logic, and control the execution order of the control logic of at least one of the functional units; at least one of the functional units is used to receive the state quantity signal, and execute the corresponding control logic according to the state quantity signal.

[0006] Optionally, the timing control unit includes at least one judgment unit and a model state management unit, the judgment unit is used to receive an input signal, and when it is judged that a logical enable condition is met according to the input signal, output a first enable flag, wherein the first enable flag is used to mark the running state of the model; the model state management unit is used to determine the running state of the software model and the state quantity signal according to the first enable flag, wherein the running state of the software model corresponds to the state quantity signal.

[0007] Optionally, the software model includes multiple operating states, and different states are independent of each other.

[0008] Optionally, the first enable flag corresponds to the control logic. If the first enable flag is a first value, the software model architecture enables the corresponding control logic and enters a state corresponding to the control logic; if the first enable flag is a second value, the software model architecture cannot enable the corresponding control logic, and the software model architecture exits the state corresponding to the control logic.

[0009] Optionally, the model state management unit is specifically used to update the running state of the software model according to the state entered or exited by the model, and determine a state quantity signal corresponding to the updated state.

[0010] Optionally, at least one of the functional units is also used to output signals to the outside of the software model architecture, or at least one of the functional units is also used to output signals to other functional units, or at least one of the functional units outputs signals to the timing control unit.

[0011] Optionally, the functional unit includes a logic trigger unit and a logic execution unit, the logic trigger unit is used to receive the state quantity signal output by the timing control unit, and output a second enable flag according to the state quantity signal, the second enable flag is used to trigger the logic execution unit to execute the control logic; the logic execution unit is used to receive the second enable flag, execute the corresponding control logic according to the second enable flag, and output the logic signal.

[0012] Optionally, a plurality of the state quantity signals correspond to one functional unit, or a single state quantity signal corresponds to a plurality of the functional units.

[0013] Optionally, the logic execution unit includes a master unit and at least one slave unit, the master unit is used to control the logic execution timing in at least one of the slave units; and at least one of the slave units is used to execute corresponding logic.

[0014] According to the second aspect of the present application, a battery management system controller is also provided, which includes a control chip and a software model architecture set on the control chip, and the software model architecture is any software model architecture described in the first aspect.

[0015] According to a third aspect of the present application, a vehicle is also provided, comprising a battery management system controller as described in any one of the second aspects.

[0016] One beneficial effect of the present application is that the model architecture of this embodiment includes a timing control unit and at least one functional unit connected to the timing control unit. The trigger scheduling of the functional unit is uniformly controlled by the timing control unit as a whole. This can avoid the problem that multiple functional units are independent of each other, each unit executes different logics, and multiple units cannot coordinate and cooperate effectively. The control logic between multiple units can be coordinated to ensure the overall stable and accurate operation of the model.

[0017] Other features and advantages of the embodiments of the present application will become apparent from the following detailed description of exemplary embodiments of the present application with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the present application and, together with the description, serve to explain the principles of the embodiments of the present application.

[0019] Figure 1 This is an architectural diagram of an embedded software model architecture provided by an embodiment of the present application.

[0020] Figure 2 This is an architectural diagram of a timing control unit provided in one embodiment of the present application.

[0021] Figure 3 It is an architectural diagram of a functional unit provided by an embodiment of the present application.

[0022] Figure 4 It is a logic schematic diagram of a logic trigger unit provided in one embodiment of the application.

[0023] Figure 5 This is an architectural diagram of a logic execution unit provided in one embodiment of the present application.

[0024] Figure 6 It is a flowchart of a trigger function unit provided in this embodiment of the present application.

[0025] Figure 7 This is a schematic diagram of a battery management system controller provided in this embodiment of the present application.

[0026] Figure 8 It is a schematic diagram of a vehicle provided in this embodiment of the present application. DETAILED DESCRIPTION

[0027] Various exemplary embodiments of the present application will now be described in detail with reference to the accompanying drawings. It should be noted that the relative arrangement of components and steps, numerical expressions and numerical values ​​set forth in these embodiments do not limit the scope of the present invention unless otherwise specifically stated.

[0028] The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the invention, its application, or uses.

[0029] Technologies, methods, and equipment known to ordinary technicians in the relevant art may not be discussed in detail, but where appropriate, the technologies, methods, and equipment should be considered as part of the specification.

[0030] In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not limiting. Therefore, other examples of the exemplary embodiments may have different values.

[0031] It should be noted that like reference numerals and letters refer to similar items in the following figures, and therefore, once an item is defined in one figure, it need not be further discussed in subsequent figures.

[0032] It should be noted that all actions of acquiring signals, information or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where they are located, and with the authorization given by the owner of the corresponding device.

[0033] Figure 1 It is an architecture diagram of an embedded software model architecture provided by an embodiment of the present application. The architecture diagram of the embedded software model architecture may include a timing control unit and at least one functional unit. The timing control unit is used to receive an input signal and output a state quantity signal to the functional unit according to the input signal. The state quantity signal is used to trigger at least one of the functional units to execute a corresponding control logic and control the execution order of the control logic of at least one functional unit. At least one functional unit is used to receive a state quantity signal and execute a corresponding control logic according to the state quantity signal.

[0034] The model architecture of this embodiment includes a timing control unit and at least one functional unit connected to the timing control unit. The trigger scheduling of the functional units is uniformly controlled by the timing control unit as a whole. This can avoid the problem that each functional unit cannot effectively cooperate as a whole due to executing corresponding independent logic. The control logic between multiple units is coordinated to ensure the overall stable and accurate operation of the model.

[0035] The existing solution needs to add an interface for each functional unit, and realize the linkage between the functional units through the transmission control of the interface. This method adds a large number of interfaces, and the architecture maintenance is relatively complex, and the workload is large. Moreover, the existing solution is easy to cause time conflicts between functional units, and the precise control of logic execution cannot be achieved. In the embodiment of the present application, a timing control unit is added inside the software model architecture, and the timing control unit is used as the main unit to uniformly control the functional units, and the functional units are used as slave units to trigger the corresponding control logic according to the timing scheduling. The technical solution of the embodiment of the present application can uniformly trigger the logic of the slave unit through the main unit. This model architecture can be applied to the stable and precise control of all projects, will not cause time conflicts between functional units, can also reduce the addition of a large number of interfaces on the hardware, save cost and time, and improve the overall operation ability of the software model architecture.

[0036] The timing control unit can receive signals from the outside and other units, define the control logic that needs to be executed in each cycle of the software model from the beginning to the end of the operation, and the order in which the control logic is executed. The timing control unit can lock different control logics that need to be executed into different model states. In each model state, the timing control unit can output state quantity signals to other units and control the scheduling of other units through the state quantity signals.

[0037] The input signal of the timing control unit can be a signal input from the outside of the software model architecture, or a signal returned by a functional unit. The timing control unit can comprehensively determine the entry and exit conditions of the software model architecture state based on the received signal. The output signal of the timing control unit can be a state quantity signal, which controls other scheduling units through the state quantity signal.

[0038] Functional units no longer need to transmit control enable signals to each other, but instead receive the state quantity signal sent by the timing control unit. Each functional unit can determine whether the value of the state quantity signal is the value that triggers the logic of this unit. If so, the logic of the functional unit is enabled and the output signal is updated; otherwise, the logic of the functional unit is not enabled and the output signal is not updated. Functional units can transmit output signals to other functional units, outside the software model architecture, or the timing control unit.

[0039] A state quantity signal of the software model architecture can correspond to the triggering of multiple functional unit control logics. The triggering of a functional unit control logic can also correspond to multiple state quantity signals of the software model architecture.

[0040] The timing control unit is equivalent to the brain of the entire software model architecture, controlling the entire software model architecture. There can be multiple functional units, which can be laid out flatly in this software model architecture and connected to the timing control unit, and uniformly accept the control of the timing control unit.

[0041] Figure 2 : This is an architecture diagram of a timing control unit provided by an embodiment of the present application. As an embodiment, the timing control unit may include at least one judgment unit and a model state management unit. The judgment unit is used to receive an input signal, and when it is judged according to the input signal that a logical enable condition is satisfied, output a first enable flag. The first enable flag is used to mark the running state of the model. The model state management unit is used to determine the running state of the software model and the state quantity signal according to the first enable flag. The running state of the software model corresponds to the state quantity signal.

[0042] The input signal used in the judgment unit to judge the logic enable condition can be a signal input from outside the software model architecture, a signal input from the functional unit, or a combination of input signals from outside the software model architecture and from the functional unit.

[0043] There can be multiple judgment units, such as Figure 2 Different judgment conditions can be set for different judgment units such as judgment unit 1 and judgment unit 2. Multiple judgment units can be arranged in parallel and arranged on the left and right of the model state management unit, so that multiple judgment units can output signals to the model state management unit together.

[0044] As an embodiment, the first enable flag corresponds to the control logic. If the first enable flag is a first value, the software model architecture enables the corresponding control logic and enters the state corresponding to the control logic. If the first enable flag is a second value, the software model architecture cannot enable the corresponding control logic, and the software model architecture exits the state corresponding to the control logic. Here, the first value and the second value can be pre-set values, or they can be common terms set according to common program rules. For example, if the model enables a certain logic, the enable flag of the logic is set to True, the model enters the state corresponding to the logic and remains in the state, and the first value is True. If the logic cannot be enabled, the enable flag of the logic is False, the model exits the state, and the second value is False. Among them, the more complex the overall logic of the model, the more subdivided the logic will be, and the more judgment units there will be in the timing control unit, and the more running states of the model will be.

[0045] As an embodiment, the model state management unit is specifically used to update the running state of the software model according to the state entered or exited by the model, and determine the state quantity signal corresponding to the updated state.

[0046] The model state management unit can receive all enable flags (e.g., the first enable flag), and in each state of the software model architecture, according to the control logic and the value of the enable flag, update the running state of the software model to a new state or maintain the current state, and update the model state quantity signal at the same time. The model state quantity signal can be output to each functional unit, and the scheduling of all functional units can be controlled by the change of the model state quantity signal.

[0047] In terms of layout, the model state management unit can be set on the right side of the timing control unit to receive the signals output by all the judgment units, which can facilitate signal transmission.

[0048] As an embodiment, the software model includes multiple running states, and different states are independent of each other. Different states are independent of each other, so that the state quantity signals output by the model state management unit are different, and the uniqueness of each state can be maintained, making the overall logic more orderly.

[0049] Different states can be complementary to each other. In other words, when a model state is exited, it must enter other model states to maintain smooth jumps between model states and prevent state stagnation.

[0050] The following example illustrates the logic of the model jumping between different states.

[0051] (1) When the program starts, the model state is in the initialization state and the output state quantity is Condition0.

[0052] (2) After the model is initialized, if any enable flag in State 1, State 2, or State 3 is True, the corresponding state is entered and the state quantity Condition 1, Condition 2, or Condition 3 is output; otherwise, the model remains in the initialization state.

[0053] (3) In any state of state 1, state 2, or state 3, if the enable flag is False, there is at least one other enable flag that is True, and the model state enters the corresponding other state.

[0054] In the above example, the four states of state 0, state 1, state 2, and state 3 are independent of each other, and the output state quantity signals are also different. After receiving the state quantity signal, other units can determine whether to trigger the corresponding control logic.

[0055] Figure 3 This is an architectural diagram of a functional unit provided by an embodiment of the present application.

[0056] As an embodiment, at least one functional unit is also used to output signals to the outside of the software model architecture, or at least one functional unit is also used to output signals to other functional units, or at least one functional unit outputs signals to a timing control unit.

[0057] Functional units can output signals to other units or to the outside, but there is no need for functional units to transmit enable signals to each other. Instead, they uniformly receive status quantity signals sent by the timing control unit, or receive signals input from outside the software model architecture, or signals input from other functional units.

[0058] As an embodiment, the functional unit may include a logic trigger unit and a logic execution unit, wherein the logic trigger unit is used to receive the state quantity signal output by the timing control unit and output the second enable flag according to the state quantity signal, and the second enable flag is used to trigger the logic execution unit to execute the control logic; the logic execution unit is used to receive the second enable flag, execute the corresponding control logic according to the second enable flag, and output the logic signal. Figure 4 The figure is a logic diagram of a logic trigger unit provided in one embodiment of the application. The logic trigger unit can be triggered by the enable judgment of the logic unit.

[0059] The control logic of each functional unit will match the state of the corresponding software architecture model. By judging whether the value of the current state quantity signal is equal to the value that triggers the control logic, it can be used to determine whether to trigger the logic of the functional unit. If they are equal, the logic of the functional unit is triggered, otherwise it is not triggered.

[0060] According to the logic complexity of the functional unit, in order to achieve stable control of its internal running timing, the functional unit can be divided into master unit and slave unit. The master unit can be a logic trigger unit, which can control the timing. The slave unit can be a logic execution unit, which triggers and executes the logic. In addition, each master unit or slave unit can be further divided into small master and slave units until the logic is simple and does not need to be divided. In this way, the software model architecture is nested from outside to inside and from top to bottom to control the running timing of the entire model.

[0061] As an embodiment, a plurality of the state quantity signals correspond to one functional unit, or a state quantity signal corresponds to a plurality of functional units.

[0062] A state quantity signal of the software architecture model can correspond to the triggering of multiple functional unit logics. The triggering of a functional unit logic can also correspond to multiple state quantity signals of the software architecture model. In this way, the correspondence between state quantity signals and functional units can be flexibly set according to the specific strategy of the model.

[0063] Figure 5This is an architectural diagram of a logic execution unit provided in one embodiment of the present application.

[0064] When the logic trigger unit triggers the corresponding logic execution unit, the triggered logic execution unit executes the policy logic and outputs the updated signal. If it is determined not to be triggered, the policy is not executed and the output signal is not updated. The logic execution unit can determine whether it is triggered by the received enable flag (second enable flag).

[0065] As an embodiment, the logic execution unit may include a master unit and at least one slave unit. The master unit may be used to control the logic execution timing in the at least one slave unit. The at least one slave unit may be used to execute the corresponding logic.

[0066] If the logic of a certain functional unit is very complex, the triggered logic execution unit can be divided into multiple sub-units according to the function and time scheduling. At this time, in order to stably and accurately control the running timing of the logic unit and ensure that the timing of each sub-unit is normal and does not conflict with each other, you can add a timing control sub-unit to the logic execution unit according to the master-slave unit division idea of ​​the model to schedule the function triggering of other sub-units. Not only that, if the logic of the divided sub-unit is still complex, you can continue to divide the master-slave unit until the control logic is simple and the timing control is intuitive and clear. This nested architecture method of dividing the master-slave unit can stably control the running timing of the model from the outside to the inside and from top to bottom, and is suitable for all projects.

[0067] Figure 6 This is a flow chart of a logic trigger function unit provided in this embodiment, and four state quantities are used as an example for illustration.

[0068] Here, four state quantity signals are used as examples to illustrate the trigger logic of the logic execution unit of all functional units in the software architecture model. The specific execution steps are as follows:

[0069] 111, start.

[0070] 112, determine whether the state quantity signal is Condition 0. If the determination result is yes, the process proceeds to 113. If the determination result is no, the process proceeds to 114.

[0071] 113, the control logic of any functional unit is not executed.

[0072] 114, determine whether the state quantity signal is Condition 1. If the determination result is yes, the process proceeds to 115. If the determination result is no, the process proceeds to 116.

[0073] 115, executes the control logic of functional unit 1.

[0074] 116, determine whether the state quantity signal is Condition 2. If the determination result is yes, the process proceeds to 117. If the determination result is no, the process proceeds to 118.

[0075] 117, executes the control logic of functional unit 2.

[0076] 118, determine whether the state quantity signal is Condition 3. If the determination result is yes, the process proceeds to 119. If the determination result is no, the process proceeds to 120.

[0077] 119, executes the control logic of functional unit 3.

[0078] 120, no logic is executed.

[0079] In summary, (1) if the state quantity signal output by the timing control unit is Condition0, it means that the model is in the initialization state and the logic of any functional unit is not triggered at this time.

[0080] (2) If the state quantity signal output by the timing control unit is Condition 1, Condition 2, or Condition 3, it means that the model is in state 1, state 2, or state 3. At this time, according to the corresponding relationship, the logic of the functional unit corresponding to the state is triggered. One, two, or more functional units may be triggered.

[0081] (3) If the triggering condition of a certain functional unit (such as triggering functional unit 2) is met, the logic of the functional unit (such as functional unit 2) is executed. If the triggering condition of any functional unit is not met, the control logic of any functional unit is not triggered.

[0082] In the embodiment of the present application, a one-master-multiple-slave, nested-layer strategy is adopted, which can achieve stable and accurate control of the timing of the entire complex model as a whole. The implementation is simple and does not require the addition of a large number of interfaces. The complexity of model maintenance can be reduced, thereby improving the reliability of the software construction model and is suitable for models of all projects.

[0083] Embedded software development in the vehicle field is increasingly adopting model design to meet the growing functional requirements. It can be seen that the vehicle using the embedded software model architecture of this embodiment can use the timing control unit to uniformly control the trigger scheduling of the functional units as a whole, so as to avoid the problem that multiple functional units are independent of each other, each unit executes different logics, and multiple units cannot coordinate and cooperate effectively, so as to coordinate the control logic between multiple units and ensure the overall stable and accurate operation of the model.

[0084] Figure 7 This is a schematic diagram of a battery management system controller provided in this embodiment of the present application.

[0085] The battery management system controller 300 includes a control chip 200 and a software model architecture 100 disposed on the control chip 200. The software model architecture 100 is Figure 1 The software model architecture shown in the figure. The specific structure and function of each module are described in the above embodiments, and will not be repeated here to avoid repetition.

[0086] The battery management system controller provided in this embodiment includes a software model architecture set on the control chip of the battery management system controller. The software model architecture includes a timing control unit and at least one functional unit connected to the timing control unit. The trigger scheduling of the functional unit is uniformly controlled by the timing control unit as a whole. This can avoid the problem that multiple functional units are independent of each other, each unit executes different logics, and multiple units cannot coordinate and cooperate effectively. The control logic between multiple units is coordinated to ensure the stable and accurate operation of the overall model and the battery management system controller.

[0087] Figure 8 FIG. 4 is a schematic diagram of a vehicle provided in an embodiment of the present application. The vehicle 400 includes the battery management system controller 300 of the above embodiment.

[0088] The battery management system controller 300 includes a control chip 200 and a software model architecture 100 disposed on the control chip 200. The software model architecture 100 is Figure 1 The software model architecture shown.

[0089] Embedded software development in the vehicle field is increasingly using model design to meet the growing functional requirements. It can be seen that the vehicle 400 using the battery management system controller 300 of this embodiment can coordinate the timing between the units in an orderly manner to ensure the overall stable and accurate operation of the model because the battery management system controller 300 has a software model architecture 100.

[0090] The present invention may be a system, a method and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for causing a processor to implement various aspects of the present invention.

[0091] A computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples of computer-readable storage media (a non-exhaustive list) include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, such as a punch card or a raised structure in a groove on which instructions are stored, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium is not to be interpreted as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse through a fiber optic cable), or an electrical signal transmitted through a wire.

[0092] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in the computer-readable storage medium in each computing / processing device.

[0093] The computer program instructions for performing the operation of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages, such as Smalltalk, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. Computer-readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as an independent software package, partially on a user's computer, partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider to connect via the Internet). In some embodiments, an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may be personalized by utilizing the state information of the computer-readable program instructions, and the electronic circuit may execute the computer-readable program instructions, thereby realizing various aspects of the present invention.

[0094] Various aspects of the present invention are described herein with reference to the flow charts and / or block diagrams of the methods, devices (systems) and computer program products according to embodiments of the present invention. It should be understood that each box of the flow chart and / or block diagram and the combination of each box in the flow chart and / or block diagram can be implemented by computer-readable program instructions.

[0095] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, so that when these instructions are executed by the processor of the computer or other programmable data processing device, a device that implements the functions / actions specified in one or more boxes in the flowchart and / or block diagram is generated. These computer-readable program instructions can also be stored in a computer-readable storage medium, and these instructions cause the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable medium storing the instructions includes a manufactured product, which includes instructions for implementing various aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0096] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operating steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0097] The flow charts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the systems, methods and computer program products according to multiple embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a part of a module, a program segment or an instruction, and a part of the module, a program segment or an instruction contains one or more executable instructions for realizing the specified logical function. In some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions. It is well known to those skilled in the art that it is equivalent to implement it by hardware, implement it by software, and implement it by combining software and hardware.

[0098] Embodiments of the present invention have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the marketplace, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein. The scope of the present invention is defined by the appended claims.

Claims

1. An embedded software model architecture, characterized in that: include: A timing control unit and at least one functional unit; The timing control unit is used to receive an input signal and output a state quantity signal to the functional unit according to the input signal, wherein the state quantity signal is used to trigger at least one of the functional units to execute a corresponding control logic and control the execution order of the control logic of at least one of the functional units; At least one of the functional units is used to receive the state quantity signal and execute corresponding control logic according to the state quantity signal; The timing control unit includes at least one judgment unit and a model state management unit. The judging unit is used to receive an input signal, and output a first enabling flag bit when judging that a logic enabling condition is satisfied according to the input signal, wherein the first enabling flag bit is used to mark the running state of the model; The model state management unit is used to determine the running state of the software model and the state quantity signal according to the first enable flag, wherein the running state of the software model corresponds to the state quantity signal.

2. The embedded software model architecture according to claim 1, characterized in that: The software model has multiple operating states, and different states are independent of each other.

3. The embedded software model architecture according to claim 1 or 2, characterized in that: The first enable flag bit corresponds to the control logic, If the first enable flag is a first value, the software model architecture enables the corresponding control logic and enters a state corresponding to the control logic; If the first enable flag is the second value, the software model architecture cannot enable the corresponding control logic, and the software model architecture exits the state corresponding to the control logic.

4. The embedded software model architecture according to claim 3, characterized in that: The model state management unit is specifically used to update the running state of the software model according to the state entered or exited by the model, and to determine a state quantity signal corresponding to the updated state.

5. The model architecture according to claim 1, characterized in that At least one of the functional units is further configured to output a signal to the outside of the software model architecture, or, At least one functional unit is further configured to output a signal to other functional units, or, At least one functional unit outputs a signal to the timing control unit.

6. The embedded software model architecture according to claim 1, characterized in that: The functional unit includes a logic trigger unit and a logic execution unit. The logic trigger unit is used to receive the state quantity signal output by the timing control unit, and output a second enable flag bit according to the state quantity signal, wherein the second enable flag bit is used to trigger the logic execution unit to execute the control logic; The logic execution unit is used to receive the second enable flag, execute corresponding control logic according to the second enable flag, and output a logic signal.

7. The embedded software model architecture according to any one of claims 1, 2, 4-6, characterized in that: A plurality of the state quantity signals correspond to one functional unit, or a single state quantity signal corresponds to a plurality of the functional units.

8. The embedded software model architecture according to claim 6, characterized in that: The logic execution unit includes a master unit and at least one slave unit, The master unit is used to control the logic execution timing in at least one of the slave units; At least one of the slave units is used to execute corresponding logic.

9. A battery management system controller, characterized in that: The battery management system controller includes a control chip and a software model architecture arranged on the control chip, and the software model architecture is the software model architecture described in any one of claims 1-8.

10. A vehicle, characterized in that: The vehicle includes the battery management system controller of claim 9.

Images