An embedded test software component library for hardware interface and its design method

Abstract

The invention discloses an embedded test software component library facing hardware interface and a design method thereof, comprising a file system, a database system and a component description file; the file system is used to store source files of test software components; wherein the source files of the test software components are developed according to the embedded test software component model facing hardware interface; the database system is used to store preset typical information of different types of test software components by using different data tables according to the types of test software components; the component description file is used for linking between the file system and the database system; specifically, the preset key information associated between the file system and the database system is described by XML description language; the invention adapts to the traditional software development mode, realizes the reuse of source code level, and can provide better support for the high-quality and high-reliability development of embedded software.

Description

Technical Field

[0001] The invention belongs to the technical field of embedded software development, and in particular relates to an embedded test software component library oriented to a hardware interface and a design method thereof, and is particularly suitable for aerospace embedded test software. Background Art

[0002] There have been many technical achievements in the development technology of software components and the formulation of component library standards. The existing typical component models include OMG (International Object Management Group) CORBA / CCM (Common Object Request Broker Architecture), SUN's EJB and Microsoft's COM / DCOM / .NET. Among them, COM / DCOM / .NET technology solves the problem of code confusion in programming by relying on the characteristics of programming language, EJB technology fundamentally changes the cross-platform problem of components, and CORBA technology provides distributed services and visual controls based on middleware.

[0003] At present, component technology has been applied in many fields. The JAVA and .NET technologies currently used by the entire software industry can develop components. Secondly, many large commercial companies have begun to establish their own component libraries. For example, the services provided by Alibaba Cloud and Baidu Cloud are also a form of component. However, most of the above-mentioned component technologies are based on Internet applications. However, when it comes to embedded testing software for hardware interfaces, due to the strong correlation between embedded software and hardware, each embedded software has relatively independent design requirements. The existing component technology standards cannot be directly applied to the design and development of embedded software components. Summary of the invention

[0004] In view of the technical problems existing in the prior art, the present invention provides an embedded test software component library oriented to a hardware interface and a design method thereof, so as to solve the technical problem that the existing component technical standards cannot be directly applied to the design and development of embedded software components.

[0005] In order to achieve the above object, the technical solution adopted by the present invention is:

[0006] The present invention provides an embedded test software component library for hardware interfaces, including a file system, a database system and a component description file;

[0007] The file system is used to store source files of test software components; wherein the source files of the test software components are developed according to an embedded test software component model oriented to a hardware interface;

[0008] The database system is used to store preset typical information of different types of test software components using different data tables according to the types of test software components;

[0009] The component description file is used for linking the file system with the database system; specifically, the preset key information associated with the file system and the database system is described by XML description language.

[0010] Furthermore, the process of establishing the source file of the test software component is as follows:

[0011] According to the requirements of the embedded test software component model for hardware interfaces, the description information of the test software component is defined for the test software component to be developed; according to the defined description information of the test software component, the test software components for different hardware interfaces are developed, and the source files of the test software components are obtained.

[0012] Furthermore, the hardware interface-oriented embedded test software component model includes a description model, an interface model and an operation model; wherein the description model is used to support the management and retrieval of test software components, the interface model is used to implement the configuration and connection of test software components, and the operation model is used to complete the preset functions of the components.

[0013] Furthermore, the source files of the test software component include a component program file and a component program description file; wherein the component program file and the component program description file are stored separately.

[0014] Furthermore, the file system uses a four-level directory structure to store the source files of the test software component; wherein the specific implementation method of using the four-level directory structure to store the source files of the test software component is:

[0015] The first level directory is the test software component file library; the second level directory includes the component information library and the description information library; under the component information library, there are three levels of sub-directories, including sub-directories distinguished by test software component type, sub-directories named by component name, and sub-directories for specific implementation program files of test software components;

[0016] Under the description information base, the test software component types are classified, and all description information files of the test software component are arranged by name and stored in the corresponding test software component type directory.

[0017] Furthermore, in the description information library, all description information files of the test software components are named in the following manner: time+component type+component identification number.

[0018] Furthermore, the database system includes several component type data tables and a component description information data table;

[0019] The component type data tables correspond to different types of test software components one by one, and each component type data table stores basic information of the corresponding type of test software component; the component description information data table is used to store component instance description information of each test software component.

[0020] Furthermore, the basic information of the test software component includes common fields of the test software component and unique attribute fields of the test software component;

[0021] The common fields of the test software include component identification number, component ID number and component name, and the component identification number is used as a slave key; the unique attribute fields of the test software component include component subtype, storage component capacity and communication component interface type;

[0022] In the component description information data table, a component identification number is allocated to each component instance of the test software component as a primary key, and the secondary key corresponds to the primary key.

[0023] Furthermore, when describing the preset key information associated between the file system and the database system using the XML description language, all test software components are described using <component>Tag definition; wherein the <component>Included in the tag <description>Sub-tags,<OPRATION_ARRAY> Sub-labels and<INTERFACE_ARRAY> Sub-tags;

[0024] Among them, the <description>The subtag is used to define the description of the test software component;<OPRATION_ARRAY> The subtag is used to declare the executable actions of the test software component;<INTERFACE_ARRAY> The subtag is used to declare the interface for connection or data exchange between test software components.

[0025] The present invention also provides a design method for an embedded test software component library oriented to a hardware interface, comprising:

[0026] According to the embedded test software component model facing the hardware interface, the source file of the test software component is developed;

[0027] Storing the source files of the test software component in a file system;

[0028] According to the types of test software components, a database system with several data tables is designed, and different data tables are used to store preset typical information of different types of test software components;

[0029] A component description file is created, in which preset key information associated between the file system and the database system is described in the component description file by using XML description language.

[0030] Compared with the prior art, the present invention has the following beneficial effects:

[0031] The invention provides an embedded test software component library facing hardware interface and a design method thereof. The file system is used to store source files of test software components, different data tables are used in a database system to store preset typical information of different types of test software components, and a component description file is used to link the file system and the database system to realize a dual storage mode of the file system and the database system. The XML description language is used in the component description file to describe preset key information associated with the file system and the database system to realize the interconnection and combination of the file system and the database system. The invention can not only meet the componentized software development method, but also perform software design through a component integration tool, adapt to the traditional software development mode, realize the reuse of source code level, and can concretize and operate the abstract componentized design concept, so that the advantages of reusability and easy transplantation provided by the component technology can provide better support for the high-quality and high-reliability research and development of embedded software.

[0032] Furthermore, according to the requirements of the embedded test software component model for hardware interfaces, the source files of the test software components are established. The embedded test software component model for hardware interfaces is oriented to hardware interfaces, is strongly related to the underlying devices, and can fully adapt to the characteristics of the rich variety of hardware device interfaces; secondly, the model is rich in connotation and concise in interface, covers all software attributes related to the hardware interface, takes into account the coding habits of traditional embedded software designers, and is easy to apply; in addition, the component reuse under the model is source code-level reuse, the component has less redundant code, and can achieve compatibility with existing function modules at the same time, and can be quickly converted into usable components. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 It is a structural block diagram of the embedded test software component model for hardware interface in the present invention;

[0034] Figure 2 A schematic diagram of a model interface of a hardware interface-oriented embedded test software component model in the present invention;

[0035] Figure 3 A schematic diagram of the storage structure of the file system in the present invention;

[0036] Figure 4 It is a schematic diagram of the structure of the database system in the present invention;

[0037] Figure 5 It is a schematic diagram of the information structure of the component description file in the present invention. DETAILED DESCRIPTION

[0038] In order to make the technical problems, technical solutions and beneficial effects solved by the present invention more clearly understood, the present invention is further described in detail in the following specific embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0039] The present invention provides an embedded test software component library for hardware interface, comprising a file system, a database system and a component description file; the file system is used to store source files of test software components; the database system is used to store preset typical information of different types of test software components using different data tables according to the types of test software components; the component description file is used for linking between the file system and the database system.

[0040] In the present invention, the source file of the test software component is developed according to the embedded test software component model oriented to the hardware interface; specifically, the process of establishing the source file of the test software component is as follows:

[0041] According to the requirements of the Embedded Testing Component Model (ETCM) for hardware interfaces, description information of the test software component is defined for the test software component to be developed; according to the defined description information of the test software component, test software components for different hardware interfaces are developed to obtain source files of the test software component; wherein the source files of the test software component include component program files and component program description files.

[0042] As attached Figure 1 As shown, the hardware interface-oriented embedded test software component model includes a description model, an interface model and an operation model. The description model is used to support the management and retrieval of test software components, the interface model is used to implement the configuration and connection of test software components, and the operation model is used to complete the preset functions of the components.

[0043] Specifically, the description model includes a description description sub-model and a query description sub-model; wherein the description description sub-model serves as the instructions for use of the test software component, and is used to introduce in detail the component functions, parameters that need to be modified during transplantation, and matters needing attention; the query description sub-model is used for component retrieval, query, and extraction; the description model specifically includes the following contents: component name, component source, component version information, component history, component application field, component type, component development tool, component development method, component operating environment, component main function, component reusability, component usage description, and keywords for component query; wherein the component usage description includes the number of times the component has been used and the number of times the component has been modified.

[0044] Specifically, the interface model includes a configuration interface sub-model, a resource interface sub-model, an input interface sub-model and an output interface sub-model, as shown in the attached Figure 2 As shown; the configuration interface submodel is used to process the data attributes related to the component functions inside the component, that is, the parameter configuration of the component; the resource interface submodel is used to define the data related to the hardware device, as a channel for the component to interact with the device data; the input interface submodel and the output interface submodel are used as functional interfaces to realize the connection between data and operations; wherein, the output interface of one component can be used as the input of one or more components to realize the connection between multiple components, and then realize the collaborative work between components.

[0045] Specifically, the operation model is an action that can be performed by the component, including hardware initialization, sending data and receiving data; wherein, the number of operation models in a hardware interface-oriented embedded test software component model can be one or more.

[0046] In the present invention, the file system is uniformly managed by the server side, the component program file and the component program description file are stored in a fixed path in the file system, and a hierarchical storage method is adopted; wherein, the component program file and the component program description file are stored separately; for the component program file, from the component type to the component instance, each corresponds to a primary file path, and each component instance is an independent unit and is stored in an independent file path, and the storage path of the component instance is stored in the component program description file and the database system at the same time, so as to facilitate positioning and searching.

[0047] As attached Figure 3 As shown, the file system uses a four-level directory structure to store the source files of the test software component; wherein, when the four-level directory structure is used to store the source files of the test software component, the details are as follows:

[0048] The first level directory is a test software component file library; the second level directory includes a component information library and a description information library, the component information library is used to store the component program files, and the description information library is used to store the component program description files.

[0049] Specifically, the component information library is divided into three levels of sub-directories, including a first level sub-directory, a second level sub-directory and a third level sub-directory.

[0050] The first-level subdirectories are subdirectories differentiated by the type of test software components, such as a communication component subdirectory, a storage component subdirectory, and a data processing component subdirectory.

[0051] The second-level subdirectories are subdirectories named after the component names, for example: the 422 sending subdirectory, 422 receiving subdirectory, CAN sending subdirectory and CAN receiving subdirectory under the communication component subdirectory, the FLASH reading subdirectory and FLASH writing subdirectory under the storage component subdirectory, and the package assembly subdirectory and unpacking subdirectory under the data processing component subdirectory.

[0052] The third-level subdirectory is a subdirectory of the specific implementation program files of the test software component; wherein the specific implementation program files of the test software component include .c files and .h files; for example: 422Send.c file subdirectory and 422Send.h file subdirectory under the 422 sending subdirectory, 422Rev.c file subdirectory and 422Rev.h file subdirectory under the 422 receiving subdirectory, CANSend.c file subdirectory and CANSend.h file subdirectory under the CAN sending subdirectory, CANRev.c file subdirectory and CANRev.h file subdirectory under the CAN receiving subdirectory, FLASHRead.c file subdirectory and FLASHRead.h file subdirectory under the FLASH reading subdirectory, FLASHWrite.c file subdirectory and FLASHWrite.h file subdirectory under the FLASH writing subdirectory, Pack.c file subdirectory and Pack.h file subdirectory under the packing subdirectory, and UnPack.c file subdirectory and UnPack.h file subdirectory under the unpacking subdirectory.

[0053] Specifically, the test software component types are classified under the description information library, and all description information files of the test software component are arranged by name and stored in the corresponding test software component type directory; wherein, under the description information library, all description information files of the test software component are named in the manner of: time+component type+component identification number; it should be noted that the component identification number under the description information library is the same as the primary key field value of the description file in the database system, and serves as the unique identification number of the test software component.

[0054] In the present invention, the database system includes several component type data tables and a component description information data table, as shown in the attached Figure 4 As shown; the component type data tables correspond one-to-one to different types of test software components, and each component type data table stores basic information of the test software component of the corresponding type; the component description information data table is used to store component instance description information of each test software component; wherein the component instance description information of the test software component includes component identification number, component name, component developer, component version number, component extension type, component usage environment, component header file storage address and component description information.

[0055] Specifically, when designing the component type data table in the database system, independent management is performed according to the type of the test software component; that is, a component type data table is established for each type of test software component to store basic information of the corresponding type of test software component; wherein the basic information of the test software component includes common fields of the test software component and unique attribute fields of the test software component; the common fields of the test software include a component identification number, a component ID number and a component name, and the component identification number is used as a slave key; the unique attribute fields of the test software component include a component subtype, a storage component capacity, a communication component interface type and a packaging method.

[0056] When designing the component description information data table in the database system, a component identification number is assigned to each component instance of the test software component and used as the primary key; and the secondary key in the component type data table corresponds to the primary key of the component description information data table to achieve the connection between the component type data table and the component description information data table, and then undertake the data interaction between the component type data table and the component description information data table.

[0057] It should be noted that in actual operation, the required test software component is first selected through the database system, and then tracked to the corresponding file system according to the storage path in the field of the test software component to achieve sharing of the entire information.

[0058] In the present invention, the component description file implements the link between the file system and the database system in the following manner: the preset key information associated with the file system and the database system is described by using the XML description language; the reason for this is that most of the current software development tools contain their own toolkits for XML parsing, and the XML description language is a very flexible markup language that can easily implement the structured description of the test software components and can easily describe the relationship attributes between the test software components; wherein the preset key information includes, for example, component name, component ID number, component development unit, component version, component type, component extension type, component use environment, component description information, component achievable functions, resource interface, configuration interface, input interface and output interface.

[0059] As attached Figure 5 As shown, the component description file includes component items, item descriptions and item definitions; wherein the component items include component description items, component operation items and component interface items; the item description content of the component description items includes component name, component ID number, component development unit, component version, component type, component extension type, component usage environment and component description information; the item definition of the component name is a combination of English letters and numbers, the item of the component ID number is defined as a unique number, the item of the component development unit is defined as the name of the development unit, the item of the component version is defined as A.BC, the version naming rule is the same as the software naming name, and the item definition of the component type is, for example, a communication component or a storage component The item definition of component extension type is reserved, the item definition of component usage environment is filled in according to the application scope of the component, and the item definition of component description information is used to describe the functions implemented by the component; the item description content of the component operation item includes the functions that the component can realize, and multiple descriptions can be used, and its item definition is the operation name; the item description content of the component interface includes resource interface, configuration interface, input interface and output interface; among them, the item definition of resource interface is related to the hardware address of registers and other components; the item definition of configuration interface is related to component initialization, etc., and is related to the hardware address offset, and requires the user to customize the parameters; the item definition of input interface or output interface is to realize component connection.

[0060] The following is an example of a component interface based on XML description language to explain the component description file in detail, as follows:

[0061] When using XML description language to describe the preset key information associated between the file system and the database system, all test software components adopt <component>Tag definition; wherein the <component>The tag includes three sub-tag items, namely: <description>Sub-tags,<OPRATION_ARRAY> Sub-labels and<INTERFACE_ARRAY> Sub-tags.

[0062] Specifically, the <description>The subtag is used to define the description of the test software component; <description>The role of sub-tag content in component development is to help users understand the basic information of components and use the characteristics of components and user needs to search for required components; among them, a complete <description>The tags look like this:

[0063] <description>

[0064] <com_name>XXXX< / com_name>

[0065] <com_id>XXXX< / com_id>

[0066] <com_author>XXXX< / com_author>

[0067] <com_version>XXXX< / com_version>

[0068] <com_type>XXXX< / com_type>

[0069] <com_ext_type>XXXX< / com_ext_type>

[0070] <com_used_env>XXXX< / com_used_env>

[0071] <com_str_description>XXXX< / com_str_description>

[0072] < / description>

[0073] It should be noted that XXXX in the above content represents the part to be filled; <description>The sub-tag contains 8 sub-tag items, including<com_name> Sub-label items,<com_id> Sub-label items,<com_author> Sub-label items,<com_version> Sub-label items,<com_type> Sub-label items,<com_ext_type> Sub-label items,<com_used_env> Sub-label items and<com_str_description> Sub-label items; among them,<com_name> The sub-tag item is used to describe the name given to the component by the component designer;<com_id> The sub-tag item is used to define the unique identification ID of the component;<com_author> The sub-tag items are used to define the designer and design unit of the component;<com_version> The sub-tag item is used to describe the version information of the component;<com_type> Sub-label items are used to describe the category of components, such as communication components, data processing components, and simulation test components;<com_ext_type> Sub-tag items are used to add extended description information for different components. For example, for a serial port component, it can be extended to describe synchronous or asynchronous working mode.<com_used_env> Sub-tag items are used to describe the usage environment of the component, such as hardware frequency, operating voltage, etc.<com_str_description> The sub-label items are used to introduce in detail the component functions, parameters that need to be modified during migration, and precautions, etc.

[0074] Specifically, the<OPRATION_ARRAY> The subtag is used to declare the executable actions of the test software component, that is,<OPRATION_ARRAY> The subtag declares a set of actions that the component can perform, and<INTERFACE_ARRAY> The interface groups defined by the subtags are different.<OPRATION_ARRAY> The operation defined by the subtag acts on the component itself, and the effect produced is also to affect the internal state or member data of the component. In object-oriented programming, the operation corresponds to the private member function of the class; among them, a complete<OPRATION_ARRAY> The sub-tags are as follows:

[0075] <OPRATION_ARRAY count=XXX>

[0076] <OPRATION id=XXXX name=‘XXXX’description=‘XXXXXXXXXXXXX’ / >

[0077] <OPRATION id=XXXX name=‘XXXX’description=‘XXXXXXXXXXXXX’ / >

[0078] <OPRATION id=XXXX name=‘XXXX’description=‘XXXXXXXXXXXXX’ / >

[0079] <OPRATION id=XXXX name=‘XXXX’description=‘XXXXXXXXXXXXX’ / >

[0080] <OPRATION id=XXXX name=‘XXXX’description=‘XXXXXXXXXXXXX’ / >

[0081] < / OPRATION_ARRAY>

[0082] It should be noted that<OPRATION_ARRAY> The subtag contains an attribute count, which indicates the number of operations the component has; therefore,<OPRATION_ARRAY> The full form of the subtag should be<OPRATION_ARRAY count=XXX> ;<OPRATION_ARRAY> The sub-tags are grouped into <opration>Sub-tag, one <opration>The tag describes the operations that a component can perform, and includes attributes such as the operation ID number, the operation name, and the operation description, where the operation ID number is unique for each operation.

[0083] Specifically, the<INTERFACE_ARRAY> The subtag is used to declare the interface for connection or data exchange between test software components; that is,

[0084] <INTERFACE_ARRAY> The subtag declares a set of interfaces for connecting or exchanging data between components. The only medium for a component to communicate with the outside world is<INTERFACE_ARRAY> The interface defined in the subtag has a description tag of <interface>Among them, interfaces are mainly divided into four categories: configuration interface, resource interface, input interface and output interface. <interface>The type attribute in the tag indicates that the options include [inter_config], [inter_resource], [inter_func_in], and [inter_func_out]. In addition, the interface should also include attributes such as ID, name, and parameters. Among them, a complete<INTERFACE_ARRAY> The label should look like this:

[0085] <INTERFACE_ARRAY count=XXXX>

[0086] <INTERFACE id=20140423001type=‘inter_func_in’name=’setTestData’para=-1 / >

[0087] <INTERFACE id=20140423002type=‘inter_func_out’name=’getTestResult’para=-1 / >

[0088] <INTERFACE id=20140423003type=‘inter_config’name=‘cache_control__reg_addr’para=-1 / >

[0089] <INTERFACE id=20140423004type=‘inter_resource’name=‘error_reg_addr’para=-1 / >

[0090] < / INTERFACE_ARRAY>

[0091] It should be noted that<INTERFACE_ARRAY> The para in the subtag is the parameter of the interface, and the value of para is the ID of a data processing component. In fact, the data connection between any two components is completed through a data processing component. The specific implementation of the data processing component is mainly implemented by the application developer to unify the connection between interfaces.

[0092] It should be noted that the ID of each component is an important identifier. It is the main basis for establishing connections between components. The component-based development platform will map the ID to a unique component to obtain unique component information. This uniqueness is mainly guaranteed by component developers complying with unified naming rules.

[0093] In the present invention, a dual storage model of a file system and a database system is used to store components; specifically, the file system is mainly used to store specific implementation methods of various components, including .c files and .h files; the database system is mainly used to store typical information of various components, such as component names and component numbers; the component description file is used to link between the file system and the database system, and specifically uses XML description statements to describe key information associated with the file system and the database system to achieve interconnection and combination of the two systems; the present invention utilizes the dual storage method of the file system and the database system, which can not only meet the component-based software development method, and can perform software design through component integration tools, but also adapt to traditional software development and achieve source code level reuse; in addition, the database system can realize independent query of components and meet the needs of software quality management.

[0094] Design process:

[0095] The design method of the embedded test software component library for hardware interface of the present invention is as follows:

[0096] Step 1: According to the requirements of the embedded test software component model for the hardware interface, for the test software component to be developed, the description information of the test software component is defined.

[0097] Step 2: According to the description information of the test software component of the definition number, different test software components are developed for different hardware interfaces to obtain the source files of the test software components.

[0098] Step 3: Store the source files of the test software component in the file system.

[0099] Step 4: Design a database system with several data tables according to the types of test software components, and use different data tables to store preset typical information of different types of test software components.

[0100] Step 5: Create a component description file, in which preset key information associated with the file system and the database system is described in the component description file by using XML description language to realize the interconnection and combination of the file system and the database system.

[0101] Step 6: Maintain and update the component database as needed.

[0102] The embedded test software component library for hardware interface and the design method thereof described in the present invention develop the source files of the test software components according to the requirements of the embedded test software component model for hardware interface. Since ETCM is hardware interface-oriented, it is strongly related to the underlying equipment and can fully adapt to the characteristics of rich types of hardware device interfaces. Secondly, the ETCM model has rich connotations and concise interfaces, covering all software attributes related to the hardware interface, taking into account the coding habits of traditional embedded software designers, and is easy to apply. The component reuse under the ETCM model is source code-level reuse, the component has less redundant code, and can achieve compatibility with existing function modules at the same time, and can be quickly converted into available components.

[0103] In the present invention, a dual storage mode of a file system plus a database system is adopted. The storage method can not only meet the component-based software development method, but also can perform software design through a component integration tool, adapt to the traditional software development mode, realize source code level reuse, and can concretize and operationalize the abstract component-based design idea, so that the advantages of reusability and easy transplantation provided by the component technology can provide better support for the high-quality and high-reliability development of embedded software; specifically, the dual storage mode is adopted to store the entity and description of the component separately, taking into account the habits of traditional software development, and can effectively save database resources and improve the speed of component retrieval and extraction; at the same time, for the software development management completed by using the model described in the present invention, the software is not only stored as data, but also becomes reusable information flowing in the component library; the function, scale, number of changes, number of downloads, user opinions and even the information of the component developer of the component can be presented to the user as the unique business card of the component, and the above data can provide a basis for the credibility evaluation of the component, and then can provide a basis for the credibility evaluation of the software using the component, so that the quality management of the software is no longer floating in the air, and the quality of the software has the most basic standard for quantifiable assessment.

[0104] The above embodiment is only one of the implementation methods that can realize the technical solution of the present invention. The scope of protection claimed by the present invention is not limited only to this embodiment, but also includes changes, replacements and other implementation methods that can be easily thought of by any technician familiar with the technical field within the technical scope disclosed by the present invention.< / interface> < / interface> < / opration> < / opration> < / description> < / description> < / description> < / description> < / description> < / component> < / component> < / description> < / description> < / component> < / component>

Claims

1. An embedded test software component library for hardware interfaces, characterized in that: Includes file system, database system and component description files; The file system is used to store source files of test software components; wherein the source files of the test software components are developed according to an embedded test software component model oriented to a hardware interface; The database system is used to store preset typical information of different types of test software components using different data tables according to the types of test software components; The component description file is used for linking the file system with the database system; specifically, the preset key information associated with the file system and the database system is described by XML description language; The source files of the test software component include a component program file and a component program description file; wherein the component program file and the component program description file are stored separately; The database system includes several component type data tables and a component description information data table; The component type data tables correspond to different types of test software components one by one, and each component type data table stores basic information of the test software component of the corresponding type; the component description information data table is used to store component instance description information of each test software component; When describing the preset key information associated between the file system and the database system using the XML description language, all test software components use <component>Tag definition; wherein the <component>Included in the tag <description> Sub-tags,<OPRATION_ARRAY> Sub-labels and<INTERFACE_ARRAY> Sub-tags;< / description> < / component> < / component> Among them, the <description> The subtag is used to define the description of the test software component;<OPRATION_ARRAY> The subtag is used to declare the executable actions of the test software component;<INTERFACE_ARRAY> The subtag is used to declare the interface for connection or data exchange between test software components.< / description> 2. The embedded test software component library for hardware interface according to claim 1, characterized in that: The process of establishing the source file of the test software component is as follows: According to the requirements of the embedded test software component model for hardware interfaces, the description information of the test software component is defined for the test software component to be developed; according to the defined description information of the test software component, the test software components for different hardware interfaces are developed, and the source files of the test software components are obtained.

3. The hardware interface-oriented embedded test software component library according to claim 1, characterized in that: The hardware interface-oriented embedded test software component model includes a description model, an interface model and an operation model; wherein the description model is used to support the management and retrieval of test software components, the interface model is used to implement the configuration and connection of test software components, and the operation model is used to complete the preset functions of the components.

4. The hardware interface-oriented embedded test software component library according to claim 1, characterized in that: The file system uses a four-level directory structure to store the source files of the test software component; wherein the specific implementation method of using the four-level directory structure to store the source files of the test software component is: The first level directory is the test software component file library; the second level directory includes the component information library and the description information library; under the component information library, there are three levels of sub-directories, including sub-directories distinguished by test software component type, sub-directories named by component name, and sub-directories for specific implementation program files of test software components; Under the description information base, the test software component types are classified, and all description information files of the test software component are arranged by name and stored in the corresponding test software component type directory.

5. The hardware interface-oriented embedded test software component library according to claim 4, characterized in that: In the description information base, all description information files of the test software components are named in the following manner: time+component type+component identification number.

6. The hardware interface-oriented embedded test software component library according to claim 1, characterized in that: The basic information of the test software component includes the common fields of the test software component and the unique attribute fields of the test software component; The common fields of the test software include component identification number, component ID number and component name, and the component identification number is used as a slave key; the unique attribute fields of the test software component include component subtype, storage component capacity and communication component interface type; In the component description information data table, a component identification number is allocated to each component instance of the test software component as a primary key, and the secondary key corresponds to the primary key.

7. A method for designing a hardware interface-oriented embedded test software component library as described in any one of claims 1 to 6, characterized in that: include: According to the embedded test software component model facing the hardware interface, the source file of the test software component is developed; Storing the source files of the test software component in a file system; According to the types of test software components, a database system with several data tables is designed, and different data tables are used to store preset typical information of different types of test software components; A component description file is created, in which preset key information associated between the file system and the database system is described in the component description file by using XML description language.

Images