CN108228185B - Embedded software modularization generation method and device - Google Patents
Embedded software modularization generation method and device Download PDFInfo
- Publication number
- CN108228185B CN108228185B CN201711469751.8A CN201711469751A CN108228185B CN 108228185 B CN108228185 B CN 108228185B CN 201711469751 A CN201711469751 A CN 201711469751A CN 108228185 B CN108228185 B CN 108228185B
- Authority
- CN
- China
- Prior art keywords
- module
- software module
- software
- function
- api
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/44—Encoding
- G06F8/447—Target code generation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
Abstract
The invention discloses a method and a device for modularly generating embedded software. The method comprises the following steps: after the functions, the configuration options and the basic API interface set of each software module are determined, the functions of each software module and the basic API interface set are subjected to function refinement processing, and therefore a plurality of sub-functions and API interfaces corresponding to the sub-functions are obtained. And then according to the implementation process of each sub-function, coding and debugging the software module to implement all the functions of the software module and generate a binary execution file corresponding to the software module. And further, finishing the joint debugging of each software module, and updating the binary execution files corresponding to each software module according to the debugging result. The invention also discloses an embedded software modularization generating device which can prevent the code of the generated software from leaking and realize the modularization processing of the software.
Description
Technical Field
The invention relates to the field of embedded software design, in particular to a method and a device for generating embedded software modularization.
Background
In the automotive field today, software development of Electronic Control Units (ECUs) has enabled code modular partitioning. In software development, a plurality of software modules are used, most of the modules are issued in the form of source codes or static libraries, corresponding logic connections need to be designed for the software modules in order to integrate the functions of the software modules into the ECU firmware, and then the software modules are integrated together to be compiled, linked and debugged to generate the final ECU firmware.
In the prior art, the software modules are released in a source code or static library mode, so that the risk of leakage exists, and in addition, because the software modules are integrated together, when the software modules need to be changed, such as solving of BUG (software BUG), performance updating and upgrading and the like, the logical connection relation of the ECU firmware needs to be readjusted, and the processes of compiling, linking, debugging and reissuing are re-executed, so that the updating and the maintenance of the ECU firmware are not facilitated.
Disclosure of Invention
In view of this, the present invention provides a method and an apparatus for generating an embedded software module, which release software in a form of a binary execution file to prevent software codes from leaking, and add a module header to each software module to implement modular processing on the software and implement calling between the software modules.
In order to achieve the above object, the following solutions are proposed:
an embedded software modularization generating method comprises the following steps:
step A: determining the function, configuration options and a basic API interface set of each software module;
and B: dividing the function of each software module and the basic API interface set to determine a plurality of sub-functions of the software module and the API interface corresponding to each sub-function, and determining the implementation process of each sub-function;
and C: according to the implementation process of each sub-function of each software module, the API interface corresponding to each sub-function and the configuration options, carrying out coding debugging on the software module to generate a binary execution file corresponding to the software module;
the binary execution file comprises an execution code of the software module and a module head which needs to be opened to the outside;
step D: and performing combined debugging on each software module, and updating the binary execution file according to a debugging result.
Preferably, step B is followed by: and evaluating the resource consumption condition of the software module to determine the resource occupation size of the software module.
Preferably, the execution code is a binary machine code, and the module header includes: module description information, module initialization vectors, API vector tables, callback function vectors, and module configuration information.
Preferably, step C is followed by: and generating a module use description document, an API (application program interface) definition document and a template project corresponding to the software module so as to conveniently operate the software module.
Preferably, the method further comprises the following steps:
judging whether each software module is subjected to function upgrading;
if yes, repeating the steps B to D to update the binary machine code and the module head in the binary execution file.
Preferably, the method further comprises the following steps:
judging whether the software module carries out bug repair or not;
if yes, repeating the step B to the step D to update the binary machine code in the binary execution file and the module description information in the module header.
An embedded software modularization generating apparatus, comprising:
the information acquisition module is used for determining the functions, configuration options and a basic API (application program interface) set of each software module;
the function and API interface dividing module is used for carrying out detailed processing on the function and the basic API interface set of each software module so as to determine a plurality of sub-functions of the software module and an API interface corresponding to each sub-function and determine the implementation process of each sub-function;
the code debugging module is used for performing code debugging on the software module according to the implementation process of each sub-function of each software module, the API interface corresponding to each sub-function and the configuration options, and generating a binary execution file corresponding to the software module;
the binary execution file comprises an execution code of the software module and a module head which needs to be opened to the outside;
and the verification module is used for performing combined debugging on each software module and updating the binary execution file according to the debugging result.
Preferably, the execution code is a binary machine code, and the module header includes: module description information, module initialization vectors, API vector tables, callback function vectors, and module configuration information.
Preferably, the method further comprises the following steps:
and the first judgment unit is used for judging whether the software module is subjected to function upgrading.
Preferably, the method further comprises the following steps:
and the second judging unit is used for judging whether the software module carries out bug repair.
According to the technical scheme, the invention discloses a method and a device for generating embedded software modularization. After the functions, the configuration options and the basic API interface set of each software module are determined, the functions of each software module and the basic API interface set are subjected to function refinement processing, and therefore a plurality of sub-functions and API interfaces corresponding to the sub-functions are obtained. And then, according to the implementation process of each sub-function, the software module is coded and debugged to implement all the functions of the software module and generate a binary execution file corresponding to the software module. And further, finishing the joint debugging of each software module, and updating the binary execution files corresponding to each software module according to the debugging result. Compared with the prior art, the software is released in the form of binary execution files, so that software codes are prevented from being leaked, and meanwhile, the modular processing of the software is realized by adding the module heads in each software module, so that the calling among the software modules is realized.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
FIG. 1 is a flow chart of a method for generating modularity of embedded software according to an embodiment of the present invention;
FIG. 2 illustrates a software module interaction diagram disclosed by one embodiment of the present invention;
FIG. 3 is a flowchart illustrating a method for generating modularity for embedded software according to another embodiment of the present invention;
fig. 4 shows a schematic structural diagram of an embedded software modularization generating apparatus according to another embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
Referring to fig. 1, a flowchart of an embedded software modularization generating method disclosed by an embodiment of the invention is shown.
Step A: the functionality, configuration options, and basic API interface set of each software module are determined.
Defining the functions of each software module, planning the configuration options of each software module and defining the basic API interface set of each software module. Wherein different software modules correspond to different sets of API interfaces.
And B: and dividing the function of each software module and the basic API interface set to determine a plurality of sub-functions of the software module and the API interface corresponding to each sub-function, and determining the implementation process of each sub-function.
For each software module, the functions performed by the software module may be implemented jointly over several sub-functions. In the present invention, in order to understand the execution process of the software module in detail, it is necessary to perform a detailed processing on the function of the software module to obtain a plurality of sub-functions of the software module, and determine the API interface corresponding to each sub-function and the implementation process of each sub-function. It should be noted that, in the execution process of each sub-function, each sub-function is not necessarily in a one-to-one correspondence relationship with an API interface, and one sub-function corresponds to at least one API interface.
And C: and carrying out coding debugging on the software module according to the implementation process of each sub-function of each software module, the API interface corresponding to each sub-function and the configuration options, and generating a binary execution file corresponding to the software module.
The binary execution file comprises the execution code of the software module and a module header which needs to be opened to the outside.
After the implementation process of each subfunction of the software module is clarified and the API interface provided by the subfunction to the outside is implemented, the software module can be coded and debugged based on the configuration options of the software module so as to implement all the functions of the software module and simultaneously generate a binary execution file corresponding to the software module.
The binary execution file includes the execution code of the software module, i.e. the binary machine code, and a module header that needs to be provided to the outside. Wherein the API interface is stored in the module header in the format of an API vector table.
The module head consists of the following parts:
1. module _ Info: module description information including, but not limited to, module Magic Number (Magic Number, which may be used to mark the format of a file or protocol), software version Number, release date, copyright notice, etc.
2. Module _ Init: the module initialization vector points to the module's initialization entry function, which performs all initialization functions of the module, including initialization of the stack, global data, BSS segments, etc. BSS is an abbreviation of BlockStarted by Symbol. The BSS segment (BSS segment) generally refers to a memory area for storing global variables and static variables that are not initialized or initialized to 0 in a program, and belongs to static memory allocation.
3. Module _ Apis: the main body of the module header is called API vector table for short. The method comprises the steps that the module comprises the entry vectors of the API functions corresponding to all functions and sub-functions derived from the outside, the API entry vectors are grouped and ordered according to the functions, and the entry vectors are API interfaces.
4. Module _ Callbacks: and all callback function vectors of the module are externally exported.
5. Module _ Configurations: module configuration information.
6. Module _ OtherInfo: other information of the module.
Step D: and performing combined debugging on each software module, and updating the binary execution file according to the debugging result.
After the respective functions of the software modules are realized, the software modules can be jointly debugged so as to verify whether the functions of the software modules are still normal when the software modules work cooperatively, optimize the performance of the software modules, remove software bugs found in the joint debugging and complete the updating of the binary execution files of the software modules.
Compared with the existing software release mode, the mode has the following advantages:
1. by adding module head in the software module, the API interface is selectively added or deleted in the API vector table in the software generation process, and the module function can be selectively opened to the outside.
2. Releasing the software in binary form of machine code is more effective in preventing software code leakage than releasing the software in source code.
3. The function upgrading or bug repairing of the module only needs to ensure that the format of the module head of the module is relatively fixed, and no limitation is imposed on other parts of the module, so that the influence of the module on other modules is reduced to the minimum when the module is changed.
After the software is modularized based on the steps, technicians can realize the mutual calling among the software modules based on the module heads of the software modules. In particular, referring to fig. 2, a software module interaction diagram disclosed by one embodiment of the invention is shown. When the module A calls the API interface of the module B, the method comprises the following steps: 1. and reading the API entry vector stored in the API vector table of the module B. 2. And calling the related API function according to the API entry vector. 3. And returning an execution result to the module A after the API function of the module B is executed.
Similarly, if module B calls the API interface of module a, it needs to perform the 3 steps.
Referring to fig. 3, a flowchart of an embedded software modularization generating method disclosed by another embodiment of the invention is shown.
As can be seen from fig. 3, in the present embodiment, the method includes:
step A: the functionality, configuration options, and basic API interface set of each software module are determined.
Defining the functions of each software module, planning the configuration options of each software module and defining the basic API interface set of each software module. Wherein different software modules correspond to different sets of API interfaces.
And B: dividing the function of each software module and the basic API interface set to determine a plurality of sub-functions of the software module and the API interface corresponding to each sub-function, determining the implementation process of each sub-function, and evaluating the resource consumption condition of the software module to determine the resource occupation size of the software module.
Different from the first embodiment, in this embodiment, after the implementation process of each sub-function of the software module is clarified, the resource occupation condition of the software module needs to be evaluated to determine the size of the storage and calculation resources occupied by the software module, so as to implement reasonable allocation of the resources.
And C: and carrying out coding debugging on the software module according to the implementation process of each sub-function of each software module, the API interface corresponding to each sub-function and the configuration options, and generating a binary execution file, a module use description document, an API interface definition document and a template project corresponding to the software module.
The binary execution file comprises the execution code of the software module and a module header which needs to be opened to the outside, and the execution code is binary machine code.
Different from the previous embodiment, in the present embodiment, while the binary execution file corresponding to the software module is generated, a module usage description document, an API interface definition document, and a module project of the software module need to be generated, so as to facilitate a technician to operate the software.
Step D: and performing combined debugging on each software module, and updating the binary execution file according to the debugging result.
Step E: and judging whether each software module carries out function upgrading or bug repairing.
In subsequent software maintenance, a technician can perform function upgrade or bug repair on the software module based on user requirements.
And when determining that the software module needs to be upgraded or bug repaired, repeatedly executing the steps B to D to update the binary execution file corresponding to the software module. Here, it should be noted that, when the software is upgraded in function and bug repaired, the updated content of the binary execution file of the software module is different.
Specifically, when the software module is functionally upgraded, the updated content of the binary execution file includes the binary machine code and the module header, and several parts included in the module header need to be updated.
When the bug repair is performed on the software Module, the updated content of the binary execution file is mainly binary machine code, and in addition, the Module _ Info part in the Module header, namely the description information of the Module, also needs to be updated, and other parts in the Module header do not need to be updated.
Referring to fig. 4, a schematic structural diagram of an embedded software module generating apparatus according to another embodiment of the present invention is shown.
In this embodiment, the apparatus comprises: the system comprises an information acquisition module 1, a function and API interface dividing module 2, a coding debugging module 3 and a verification module 4.
The information acquisition module 1 is configured to determine functions, configuration options, and a basic API interface set of each software module.
The function and API interface dividing module 2 is used for carrying out refinement processing on the function and the basic API interface set of each software module so as to determine a plurality of sub-functions of the software module and an API interface corresponding to each sub-function and determine the implementation process of each sub-function;
for each software module, the functions performed by the software module may be implemented jointly over several sub-functions. In order to understand the execution process of the software module in detail, the function and API interface dividing module 2 needs to perform detailed processing on the functions of the software module to obtain a plurality of sub-functions of the software module, and determine the API interfaces corresponding to the sub-functions and the implementation processes of the sub-functions.
The coding and debugging module 3 is used for coding and debugging the software module according to the implementation process of each sub-function of each software module, the API interface corresponding to each sub-function and the configuration options, and generating a binary execution file corresponding to the software module;
the binary execution file comprises the execution code of the software module and a module header which needs to be opened to the outside. The execution code is a binary machine code.
After the implementation process of each sub-function of the software module is clarified and the API interface provided by the sub-function to the outside is implemented, the code debugging module 3 performs code debugging on the software module based on the configuration options of the software module to implement all the functions of the software module and generate a binary execution file corresponding to the software module at the same time.
The module head mainly comprises the following parts:
1. module _ Info: module description information including, but not limited to, module Magic Number (Magic Number, which may be used to mark the format of a file or protocol), software version Number, release date, copyright notice, etc.
2. Module _ Init: the module initialization vector points to the module's initialization entry function, which performs all initialization functions of the module, including initialization of the stack, global data, BSS segments, etc. BSS is an abbreviation of BlockStarted by Symbol. The BSS segment (BSS segment) generally refers to a memory area for storing global variables and static variables that are not initialized or initialized to 0 in a program, and belongs to static memory allocation.
3. Module _ Apis: the main body of the module header is called API vector table for short. The method comprises the steps that the module comprises the entry vectors of the API functions corresponding to all functions and sub-functions derived from the outside, the API entry vectors are grouped and ordered according to the functions, and the entry vectors are API interfaces.
4. Module _ Callbacks: and all callback function vectors of the module are externally exported.
5. Module _ Configurations: module configuration information.
6. Module _ OtherInfo: other information of the module.
And the verification module 4 is used for performing combined debugging on each software module and updating the binary execution file according to the debugging result.
After the respective functions of each software module are realized, the verification module 4 can perform joint debugging on each software module so as to verify whether the functions of each software module are still normal when the software modules work cooperatively, optimize the performance of the software modules, remove software bugs found in the joint debugging and complete the updating of the binary execution files of the software modules.
After the updating is completed, the updated binary execution file, the module use description, the template engineering, the API interface definition file and other files are externally issued.
In another embodiment of the disclosure, the apparatus further includes a first determining unit and a second determining unit.
The first judging unit is used for judging whether the software module is upgraded or not. When determining that the software module needs to be upgraded, the function and API interface partitioning module 2, the code debugging module 3, and the verification module 4 repeatedly execute their respective corresponding operations, so as to update the binary machine code and the module header in the binary execution file of the software module.
In particular, the updating of the module header involves all of the above-described parts of the module header.
And the second judging unit is used for judging whether the software module carries out bug repair. When it is determined that the software module needs to perform bug repair, the function and API interface partitioning module 2, the code debugging module 3, and the verification module 4 repeatedly execute respective corresponding operations, so as to update the binary machine code in the binary execution file of the software module and update the module description information in the module header.
Finally, it should also be noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
The embodiments in the present description are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (10)
1. A modular generation method of embedded software is characterized by comprising the following steps:
step A: determining the function, configuration options and a basic API interface set of each software module;
and B: dividing the function of each software module and the basic API interface set to determine a plurality of sub-functions of the software module and the API interface corresponding to each sub-function, and determining the implementation process of each sub-function;
and C: according to the implementation process of each sub-function of each software module, the API interface corresponding to each sub-function and the configuration options, coding and debugging the software module, generating a binary execution file corresponding to the software module, and publishing the software module in the format of the binary execution file;
the binary execution file comprises an execution code of the software module and a module head which needs to be opened to the outside; causing a cross-call between software modules to be made based on the module header when the binary execution file is executed;
step D: performing combined debugging on each software module, and updating the binary execution file according to a debugging result;
the module head includes: an API vector table;
wherein, the mutual calling between the software modules based on the module head comprises:
reading an API vector table of a software module to be called, wherein an API entry vector is stored in the API vector table;
calling an API function according to the API entry vector;
and receiving an execution result returned after the API function of the software module to be called is executed.
2. The method of claim 1, further comprising, after step B: and evaluating the resource consumption condition of the software module to determine the resource occupation size of the software module.
3. The method of claim 1, wherein the execution code is binary machine code, and wherein the module header comprises: module description information, module initialization vectors, API vector tables, callback function vectors, and module configuration information.
4. The method of claim 1, further comprising, after step C: and generating a module use description document, an API (application program interface) definition document and a template project corresponding to the software module so as to conveniently operate the software module.
5. The method of claim 3, further comprising:
judging whether each software module is subjected to function upgrading;
if yes, repeating the step B to the step D to update the binary machine code and the module head in the binary execution file.
6. The method of claim 3, further comprising:
judging whether the software module carries out bug repair or not;
if yes, repeating the step B to the step D to update the binary machine code in the binary execution file and the module description information in the module header.
7. An apparatus for generating embedded software modules, comprising:
the information acquisition module is used for determining the functions, configuration options and a basic API (application program interface) set of each software module;
the function and API interface dividing module is used for carrying out detailed processing on the function and the basic API interface set of each software module so as to determine a plurality of sub-functions of the software module and an API interface corresponding to each sub-function and determine the implementation process of each sub-function;
the code debugging module is used for performing code debugging on the software module according to the implementation process of each sub-function of each software module, the API interface corresponding to each sub-function and the configuration options, generating a binary execution file corresponding to the software module and issuing the software module in the format of the binary execution file;
the binary execution file comprises an execution code of the software module and a module head which needs to be opened to the outside; causing a cross-call between software modules to be made based on the module header when the binary execution file is executed;
the verification module is used for performing combined debugging on each software module and updating the binary execution file according to a debugging result;
the module head includes: an API vector table;
wherein, the mutual calling between the software modules based on the module head comprises:
reading an API vector table of a software module to be called, wherein an API entry vector is stored in the API vector table;
calling an API function according to the API entry vector;
and receiving an execution result returned after the API function of the software module to be called is executed.
8. The apparatus of claim 7, wherein the execution code is binary machine code, and wherein the module header comprises: module description information, module initialization vectors, API vector tables, callback function vectors, and module configuration information.
9. The apparatus of claim 8, further comprising:
and the first judgment unit is used for judging whether the software module is subjected to function upgrading.
10. The apparatus of claim 8, further comprising:
and the second judging unit is used for judging whether the software module carries out bug repair.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711469751.8A CN108228185B (en) | 2017-12-29 | 2017-12-29 | Embedded software modularization generation method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711469751.8A CN108228185B (en) | 2017-12-29 | 2017-12-29 | Embedded software modularization generation method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108228185A CN108228185A (en) | 2018-06-29 |
| CN108228185B true CN108228185B (en) | 2021-11-23 |
Family
ID=62645891
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711469751.8A Active CN108228185B (en) | 2017-12-29 | 2017-12-29 | Embedded software modularization generation method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108228185B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11416227B2 (en) * | 2019-01-31 | 2022-08-16 | Bayerische Motoren Werke Aktiengesellschaft | Method for executing program components on a control unit, a computer-readable storage medium, a control unit and a system |
| EP4336347A1 (en) * | 2021-05-16 | 2024-03-13 | Huawei Technologies Co., Ltd. | Controller software architecture, controller software upgrading method, controller, and device |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102495736A (en) * | 2011-12-19 | 2012-06-13 | 曙光信息产业(北京)有限公司 | Method and system for identifying software code svn version in executable file |
| CN106775912A (en) * | 2016-12-15 | 2017-05-31 | 广州视源电子科技股份有限公司 | Software distribution method and system |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7010780B2 (en) * | 2001-09-17 | 2006-03-07 | Intel Corporation | Method and system for software modularization and automatic code generation for embedded systems |
| DE102011056524A1 (en) * | 2011-12-16 | 2013-06-20 | Schneider Electric Automation Gmbh | Method for evaluating use of a power and / or function provided by an automation component |
| CN106371813B (en) * | 2015-07-23 | 2019-11-01 | 广州汽车集团股份有限公司 | A kind of electric vehicle motor controller method for producing software based on Simulink |
| CN105677418B (en) * | 2016-01-08 | 2018-10-23 | 烽火通信科技股份有限公司 | The method and system of multiple and different voice protocols are realized in access device |
| CN106055351A (en) * | 2016-05-20 | 2016-10-26 | 北京经纬恒润科技有限公司 | Development method and apparatus of control system |
-
2017
- 2017-12-29 CN CN201711469751.8A patent/CN108228185B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102495736A (en) * | 2011-12-19 | 2012-06-13 | 曙光信息产业(北京)有限公司 | Method and system for identifying software code svn version in executable file |
| CN106775912A (en) * | 2016-12-15 | 2017-05-31 | 广州视源电子科技股份有限公司 | Software distribution method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108228185A (en) | 2018-06-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN100543701C (en) | A kind of method and system that realize embedded software unconventionality testing | |
| CN106055368B (en) | application updating method and device | |
| US9317405B2 (en) | Test double generation | |
| CN108228185B (en) | Embedded software modularization generation method and device | |
| WO2009081267A2 (en) | Process for verifying computer codes and corresponding verification system | |
| US8140315B2 (en) | Test bench, method, and computer program product for performing a test case on an integrated circuit | |
| CN109814873B (en) | Code publishing method and device | |
| US7676774B2 (en) | System LSI verification system and system LSI verification method | |
| US20110047526A1 (en) | Method and a system for transforming an object model | |
| CN103677790B (en) | Software function modifying method | |
| CA2240584C (en) | Compile-time data dependency verification | |
| US20070234244A1 (en) | System and method for checking equivalence between descriptions | |
| CN110765008A (en) | Data processing method and device | |
| CN100359485C (en) | Testing device and method for flush-bonding system | |
| CN103488519B (en) | A kind of implementation method of interactive script language interpreter | |
| CN113805848B (en) | Target machine control software integration method and system | |
| CN110377367B (en) | Component configuration method and device, electronic terminal and computer readable storage medium | |
| CN105607569A (en) | Method and device which converts IL language into ladder chart | |
| JP5120103B2 (en) | Debugging method and debugging program | |
| US11200069B1 (en) | Systems and methods for generating a software application | |
| Filho et al. | Customizing the common variability language semantics for your domain models | |
| US20100293018A1 (en) | Test Model Abstraction For Testability in Product Line Engineering | |
| Conrad et al. | Model-based design for safety critical automotive applications | |
| CN116737174B (en) | Automatic subsystem generating tool and method based on open source hong Meng system | |
| CN113342555B (en) | ROM repairing method, device and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information |
Address after: 4 / F, building 1, No.14 Jiuxianqiao Road, Chaoyang District, Beijing 100020 Applicant after: Beijing Jingwei Hengrun Technology Co., Ltd Address before: 8 / F, block B, No. 11, Anxiang Beili, Chaoyang District, Beijing 100101 Applicant before: Beijing Jingwei HiRain Technologies Co.,Ltd. |
|
| CB02 | Change of applicant information | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |