CN116048518B - Automatic generation method of comprehensive avionics system security codes for antenna operating system - Google Patents
Automatic generation method of comprehensive avionics system security codes for antenna operating system Download PDFInfo
- Publication number
- CN116048518B CN116048518B CN202211421963.XA CN202211421963A CN116048518B CN 116048518 B CN116048518 B CN 116048518B CN 202211421963 A CN202211421963 A CN 202211421963A CN 116048518 B CN116048518 B CN 116048518B
- Authority
- CN
- China
- Prior art keywords
- port
- partition
- aadl
- name
- function
- 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
- 238000000034 method Methods 0.000 title claims abstract description 122
- 238000006243 chemical reaction Methods 0.000 claims abstract description 29
- 210000003462 vein Anatomy 0.000 claims abstract description 16
- 230000006399 behavior Effects 0.000 claims abstract description 10
- 238000004458 analytical method Methods 0.000 claims abstract description 8
- 238000005192 partition Methods 0.000 claims description 145
- 230000006870 function Effects 0.000 claims description 110
- 230000008569 process Effects 0.000 claims description 88
- 238000004891 communication Methods 0.000 claims description 71
- 230000000737 periodic effect Effects 0.000 claims description 30
- 238000013507 mapping Methods 0.000 claims description 26
- 238000005070 sampling Methods 0.000 claims description 23
- 230000015654 memory Effects 0.000 claims description 17
- 230000000694 effects Effects 0.000 claims description 8
- 125000004122 cyclic group Chemical group 0.000 claims description 4
- 238000013468 resource allocation Methods 0.000 claims description 3
- 230000009191 jumping Effects 0.000 claims 2
- 230000018109 developmental process Effects 0.000 description 15
- 238000011161 development Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 6
- 230000001419 dependent effect Effects 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 4
- 238000007726 management method Methods 0.000 description 3
- 238000011160 research Methods 0.000 description 3
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 101100233056 Caenorhabditis elegans ima-2 gene Proteins 0.000 description 1
- 235000006719 Cassia obtusifolia Nutrition 0.000 description 1
- 235000014552 Cassia tora Nutrition 0.000 description 1
- 244000201986 Cassia tora Species 0.000 description 1
- 229920002430 Fibre-reinforced plastic Polymers 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 239000011151 fibre-reinforced plastic Substances 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- BDHFUVZGWQCTTF-UHFFFAOYSA-M sulfonate Chemical compound [O-]S(=O)=O BDHFUVZGWQCTTF-UHFFFAOYSA-M 0.000 description 1
- 230000033772 system development Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
- 239000011800 void material Substances 0.000 description 1
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
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/42—Syntactic analysis
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Stored Programmes (AREA)
Abstract
The invention discloses a method for automatically generating a comprehensive avionic system security code for a weather operating system, which comprises the following steps: according to AADL ARINC653 accessory requirements, expressing software and hardware information of an IMA system by adopting AADL and expressing functional behaviors of the IMA system by heterogeneous components to obtain an IMA model; analyzing the IMA model through an AADL analysis module, converting model information into an abstract syntax tree and instantiating to obtain a model instance syntax tree; defining a corresponding conversion rule according to the API requirement of a vein operation system, expressing the conversion rule by using a Stringtemplate template engine, and generating a corresponding template file; extracting key information from the model instance grammar tree according to the conversion template and the safety coding requirement, and generating a configuration file from the key information; converting the model instance grammar tree into a C language grammar tree, generating corresponding frame codes and data structure codes, and converting heterogeneous components into corresponding functional codes; and bonding the generated frame codes, the data structure codes and the functional codes to obtain the executable codes facing the antenna operating system.
Description
Technical Field
The invention belongs to the technical field of safety key software, and particularly relates to an automatic generation method of a comprehensive avionic system safety code for a weather operating system.
Background
The embedded real-time system is widely applied to the fields of aerospace, weaponry, industrial control and the like, has the characteristics of high Safety, limited resources, real-time response, special hardware and the like, and has very high requirements on the Safety, reliability and other properties, and is called as a Safety-critical system (Safety-critical Systems). Avionics systems are a typical type of safety critical system.
With the continuous advancement of electronic communication technology, the architecture of avionics systems has undergone discrete, joint, comprehensive (Integrated Modular Avionics, IMA) and recently proposed intelligent open (Future Airborne Capability Environment, FACE) stages. The traditional combined avionics architecture adopts an airborne data bus to communicate computing equipment which is originally isolated from each other, and realizes the integration of display and control functions by introducing an airborne task computer, a multifunctional display and control equipment. However, this architecture may result in redundancy of hardware resources, excessive volume and weight, and limited communication by a single on-board bus transfer speed limit. Integrated avionics architecture, i.e., IMA architecture, introduces the concept of partitioning, supporting one or more avionics applications and allowing these applications to be executed independently. Each partition is isolated in terms of both time (time partition) and space (memory partition) and behaves as if it were executing on a single processor. A robust partition system allows partitions with different critical levels to run in the same core module without affecting other partitions. To support application development on an IMA architecture, the international avionics application software interface standard ARINC653 (Avionics Application Software Standard Interface) defines an application software partition operating environment for an IMA platform and a set of generic avionics application software standard interfaces between the operating system and the application software. At present, the standard is adopted by foreign VXWorks653, deOS, POK and other real-time operating systems, wherein the VXWorks653 of Fenghe company passes the A-level authentication of DO-178B. In domestic aspect, the antenna operating system developed by the middle aviation industrial computer also completely meets the ARINC653 standard.
As functional and nonfunctional requirements continue to increase, the complexity of safety critical systems increases dramatically. In recent years, model driving, especially safety key software design and development methods based on formal models, are gradually gaining wide attention in academia and industry at home and abroad. Model-driven development (Model-Driven Development, MDD) methods are proposed by the object management organization (Object Management Group, OMG). The MDD not only can carry out modeling verification on the system in the early design stage of the system, improves the safety and reliability of the system, but also can automatically generate codes through the model, saves development cost, improves software development efficiency and reduces software development time and cost on the premise of ensuring safety and reliability. Therefore, the model driven software development method becomes an important research content in the field of safety critical systems.
In the field of safety critical systems, common modeling languages include SysML, AADL, SCADE, simulink, modelica, wherein AADL is a modeling language for a safety critical embedded system proposed by american society of automotive engineers SAE (Society of Automotive Engineers), and supports software and hardware hybrid modeling of a safety critical system, which is an architecture modeling and analysis language very suitable for a safety critical system. Meanwhile, the AADL standard also provides AADL ARINC653 accessory, and the related attribute set is expanded aiming at ARINC653 standard requirements to enable the related attribute set to meet ARINC653 architecture modeling requirements.
After the model is established and analyzed and verified, the code is automatically generated, so that errors caused by manual programming can be reduced, and the code meets the coding style required by industry. Currently, modeling software such as SCADE, simulink mainly generates platform-independent codes, and engineers are required to manually add the platform-dependent codes, but manual coding may have errors, and meanwhile, manually written platform-dependent codes need to be independently verified according to airworthiness requirements. In terms of automatic code generation based on an AADL model, an OCARINA tool kit developed by Lasnier et al, paris telecommunications college, france, provides an ARINC653 platform-dependent C, ada code automatic generation method for an integrated modular avionics system architecture. Platform dependent code is generated by hard-linking the programming interface and platform dependent information into the generation algorithm, and thus, there is a large semantic difference between the high-level model and the source code. RAMSES is a model conversion and code generation tool that generates C code for POSIX, ARINC653, or OSEK compatible operating systems, but does not fully support the ARINC653 standard and is more suitable for model refinement. North navigation Wang Ying et al propose an automatic generation algorithm for RT-JAVA programming model and RT-JAVA codes for multitasking collaboration, but JAVA programming language is less used in aerospace embedded software. From domestic and foreign researches, although more tools support the conversion from an AADL model to a C language code, the method has defects in the aspects of code generation automation degree, platform correlation and the like. Meanwhile, at present, comprehensive airborne software automatic code generation research aiming at a domestic operating system is less.
Along with the continuous expansion of the scale of the comprehensive avionics system, the complexity of the system is gradually improved, the difficulty of system design, development and maintenance is increased, and the cost is increased. Therefore, the integrated avionics system security code automatic generation method oriented to the antenna operating system has important significance.
Disclosure of Invention
The invention aims to: in order to reduce errors introduced by manual coding and adapt to the existing airborne operating system, the invention provides an automatic generation method of a comprehensive avionic system safety code for a weather operating system, and the method improves software development efficiency and reduces software development time and cost on the premise of ensuring safety and reliability.
The technical scheme is as follows: the invention discloses a method for automatically generating a comprehensive avionic system security code for a weather operating system, which comprises the following steps:
step 1: according to AADL ARINC653 accessory requirements, expressing software and hardware information of an IMA system by adopting AADL and expressing functional behaviors of the IMA system by heterogeneous components to obtain an IMA model;
step 2: analyzing the IMA model through an AADL analysis module, converting model information into an abstract syntax tree and instantiating to obtain a model instance syntax tree;
Step 3: defining corresponding conversion rules according to requirements of an API manual of a vein operation system, expressing the conversion rules by using a Stringtemplate template engine, and generating corresponding template files;
step 4: extracting key information from the model instance grammar tree according to the conversion template and the safety coding requirement, and generating a configuration file from the key information; converting the model instance grammar tree into a C language grammar tree, generating corresponding frame codes and data structure codes, and converting heterogeneous components into corresponding functional codes;
step 5: and bonding the generated frame codes, the data structure codes and the functional codes to obtain the executable codes facing the antenna operating system.
The beneficial effects are that: compared with the prior art, the invention has the following advantages:
(1) The invention uses the Stringtemplate template engine to express the mapping from IMA model to C code and configuration file conversion rule, and decouples the template code from the control logic code through MVC mode, thereby improving reusability of the template code and facilitating the developer to carry out global modification on repeated errors in the code;
(2) The invention is oriented to a weather operating system, can reduce the difficulty of designing, developing and maintaining codes for related system development engineers, improves the software development efficiency, and reduces the software development time and cost.
Drawings
FIG. 1 is a code generation tool architecture diagram;
FIG. 2 is a block diagram of a code generation system;
FIG. 3 is a diagram of an abstract syntax tree structure;
FIG. 4 is a diagram of the structural relationship of a code generation tool Java package;
fig. 5 is a code generation flow chart.
Detailed Description
The process according to the invention is further elucidated below with reference to the drawings and examples.
The embodiment relates to an automatic generation method of a comprehensive avionics system security code oriented to a vein operation system and a corresponding tool implementation, wherein the tool is developed based on an AADL open source tool environment OSATE and is implemented through Eclipse plug-in development technology and StringTemplate template engine technology. Firstly, modeling the software and hardware information of IMA according to AADL ARINC653 accessory requirements, and using SCADE, SDL, C and other heterogeneous component expression systems to perform functional behaviors. The AADL parsing module provided by the OSATE is used for parsing the IMA model, converting model information into an abstract syntax tree and instantiating, wherein the abstract syntax tree structure is shown in figure 3. According to the conversion rule and the safety coding requirement, converting the model instance grammar tree into a C language grammar tree, generating corresponding frame codes and data structure codes, converting heterogeneous components into corresponding functional codes, finally bonding the codes, and generating an executable code oriented to the antenna operating system after integration.
(1) General overview of the tool
The embodiment realizes an integrated avionics system security code automatic generation tool oriented to a vein operation system based on EMF and Stringtemplate template engine technology, and an architecture diagram of the tool is shown in figure 1. A system block diagram of the entire tool is shown in fig. 2. The dependency between Java packages involved in tool development is shown in fig. 4.
(2) Modeling IMA according to AADL ARINC653 annex and extending a set of related attributes
The mapping between AADL entities and IMA entities is shown in table 1. According to the corresponding relation between the IMA entity and the AADL entity, the shared data components between the thread components in the same process can represent either blackboard communication or semaphore communication. Based on the semantic differences between the two communications, blackboard communications allow multiple threads to access the data components simultaneously, while semaphore communications allow only one thread to access the data components individually. Accordingly, a Concurrency_Control_Protocol attribute is set for the data component, specifying a Concurrency Control Protocol for exclusive access (i.e., critical area) to the shared data component. If the attribute is contained in the data member, the data member is considered to communicate as a semaphore, if not, a blackboard. In addition, the data member has no explicit direction, and for unidirectional connections the source port is located to the left of the connection symbol and the destination port is located to the right of the connection symbol. When the data component represents intra-partition communication, two-way connection is used, information can flow in two directions, access rights of ports are respectively designated through Access_Right, if a message sending party is a message sending party, write rights are provided, namely an Access_Right attribute value is set as write_only, and if a message receiving party is a message receiving party, read rights are only provided, namely an Access_Right attribute value is set as read_only.
Table 1 mapping between IMA entities and AADL entities
To support heterogeneous components such as SCADE, C, SDL, an AADL property set HMC4 acomos is defined, and a new property, property type, and property constant may be defined in the property set.
When using the default property, property type, property set of property constants provided by the OSATE, the property set may omit the property set name. When a defined set of attributes references content in other sets of attributes, the set of attributes required for the reference may be referenced using the with key.
The grammar structure of the attribute set template is as follows:
Property set<property set name>is
[with<property set or package name>]
<property type declaration>
<property declaration>
<property constant declaration>
End<property set name>；
wherein:
< property set or package name > is other property set templates to which the current property set template may refer;
< property type declaration > is an attribute type;
< property declaration > is the attribute definition;
< property constant declaration > is an attribute constant.
The functional behavior of the IMA system is expressed by heterogeneous components, the runtime properties of the heterogeneous components in the execution process are modeled by an HMC4ACoreOS property set, and the main content of the HMC4ACoreOS property set is shown in Table 2.
TABLE 2 HMC4ACoreOS Property set
| HMC4ACoreOS Attribute set | Description of the invention |
| Parameter_Connection | Connection of AADL ports to heterogeneous component parameters |
| Parameter_Binding | Binding of AADL ports to heterogeneous component parameters |
| File_Path | Heterogeneous component file path |
| Source_Language | Implementation language of heterogeneous components |
| Supported_Source_Languages | Implementation language of supported heterogeneous components |
| Source_name | Function (method) name of heterogeneous building block |
The attribute parameter_binding defines the mapping between AADL ports and heterogeneous component parameters, supporting input port, output port and bi-directional port mapping. Detailed definition of attributes as follows, the attribute parameter_connections is defined as a record type (line 1), containing three parameters, a_port (line 2), h_parameter (line 3) to describe AADL model port references, h_parameter to describe Parameter references of heterogeneous components, and parameter_type to describe that this Parameter connection is an input type (only_in), an output type (only_out) or a bi-directional type (in_out). The parameter_binding attribute is defined as a linked list of parameter_connections types (line 5) to support mapping between multiple ports defining AADL components and heterogeneous component parameters.
The attribute File_Path is defined as a linked list of aadlstring types (line 1), representing the File Path of the referenced heterogeneous component. The attribute supported_source_extensions is defined as an enumeration type (line 2), representing the implementation language type of the Supported heterogeneous components. The attribute Source_Language is defined as a linked list of supported_Source_Languages types (lines 3, 4) to support the implementation of multiple heterogeneous building blocks. The attribute source_name is defined as aadlstring type (line 5), and indicates the function (method) Name in the heterogeneous component used.
3) Implementation of AADL model semantic analysis and extraction by means of EMF
The OSATE2 was developed based on eclipse, which extracted the AADL model semantically by EMF at the bottom. EMF projects are a modeling framework and code generation tool that, according to the model specifications described in XML (AADL model code may use XML expression), can provide runtime support, transform models into efficient, semantically accurate Java classes and a set of adapter classes that allow viewing and command-based model editing.
AADL model base component interfaces are in org.osate.aadl2, including but not limited to:
bus main line interface
BusAcess main line channel connection interface
Data structure interface
Device interface
Thread interface
System System interface
Subprogram function interface
Process procedure interface
Property attribute interface
Connection interface
PortCategory Port type interface
ComponentCategory component type enumeration class
DirectionType Port direction enumeration class
Feature type enumeration class
Tools classes are in the org.ate.aadl2.utel package, including but not limited to:
aadl2adapter factory class
Aadl2InstanceUtil instance tool class
Aadl2ResourceFactoryImpl resource factory class
Aadl2resource class
Aadl2Switch conversion class
Aadl2Util tools
In addition to aadl2 underlying support, there is provided:
org.osate.xtext.aadl2.properties component property resolution class
org. Synthetic. Aadl2. Paramesupport compilation support class
org.osate.aadl2.instance model instance interface
org.osate.aadl2.instance.im model instance class
org. Sulfonate. Plugin plug-in support class
As shown in fig. 4, the code generation tool is based on OSATE plug-in engineering, where the class parsed by the IMA model is located in IMA 2c.aadlparser; after the IMA model analysis is completed, the IMA model analysis is converted into an abstract syntax tree and is packaged into a corresponding JavaBean, wherein the class related to code generation is positioned in ima2c.entity.code, and the class related to configuration file generation is positioned in ima2c.entity.corexml; classes related to the code generation engine and the code generator are located in ima2c.codegen; the related tool class needed in the code generation process is located in ima2c. The template code defined in the code generation is located in ima2c.resource; code generation log processing related classes are located in ima2 c.log; the global variable or the global function related class defined in the code generation process is located in ima2c.conf.; the third party tool class of the code generation procedure call is located in ima2c. The entry functions defined by the code generation tool and the menu file related classes are located in ima2c.
(4) Defining IMA transcoding rules for a context-oriented operating system
The comprehensive avionics system security code automatic generation oriented to the antenna operating system is divided into three layers: the system comprises a kernel layer, a partition layer and a task layer; the kernel layer has the main functions of distributing partition resources and scheduling partitions; the partition layer mainly functions to allocate process resources and start processes, and the task layer mainly expresses specific functional behaviors of the system. A flow chart of code generation is shown in fig. 5.
The code generation method of the present embodiment includes the steps of:
according to the requirements in MISRA C coding specification, defining corresponding security coding rules facing to the antenna operating system, mainly covering the aspects of parameter statement definition, format requirements, branch control, pointer use, jump control, loop control and the like in code generation.
Traversing the model instantiation grammar tree, extracting node component information, and respectively generating corresponding C codes according to the conversion rule;
the IMA kernel layer generates a system configuration file and a partition configuration file, wherein the system configuration file is module.xml and comprises information such as partition ports, partition memories, partition scheduling, inter-partition communication and the like; the partition configuration file comprises a replyment.h and a replyment.c, and comprises information such as the number of tasks in the partition, the number of communication ports, the communication in the partition and the like;
The partition layer of IMA generates a frame code and a data structure code, wherein the frame code file comprises main.c, activity.h, activity.c, global.h and global.c; the main.c file mainly comprises the contents of inter-partition communication port creation, intra-partition communication port creation, process resource allocation, process creation, process starting and the like; the activity.h and activity.c files mainly comprise intra-partition communication, inter-partition communication, periodic process scheduling, non-periodic process scheduling and other contents; the global.h file and the global.c file mainly comprise global variables and global function information; the data structure code file comprises gttypes.h and gttypes.c, and the file contains the data structure code of the AADL data component conversion generation C;
the task layer of IMA generates functional codes, which comprise a substrogram.h file and a substrogram.c file, and calls a corresponding algorithm to generate C codes according to the types of heterogeneous components, and if the heterogeneous components are the C codes, the corresponding C code files are directly referenced, and a corresponding function is called.
To ensure the overall security of the software, the relevant security coding rules are defined in combination with the characteristics of the antenna operating system and the MISRA C2012 standard, and the following rules (if violated, the violation reasons need to be noted) need to be completely complied with in the code generation process.
Rule 1: the defined parameters or keywords are prohibited from repeating with the basic type keywords or keywords in the C language, and the parameters must use type declarations.
Rule 2: the process body, loop body, if/else select statement, etc. must be bracketed, the connection of the logical expression, the macro parameters must be bracketed.
Rule 3: the case statement of the switch is prohibited from having any executable statement or default statement.
Rule 4: prohibiting assignment of the parameter pointer to the process pointer; disabling multi-level pointers (more than two levels); the declaration of the procedure as a pointer type is prohibited.
Rule 5: the loop traversal must use local declarations and the type is specification compliant.
Rule 6: an else branch must be used in the else if statement, with no executable statement for the else branch that prohibits conditional discrimination.
Rule 7: prohibiting the variable of the void type from being transferred as a parameter; multiple related functions are prohibited from being invoked in the same expression.
The relevant code templates are defined according to transcoding rules under the requirement of ensuring compliance with the MISRA C standard.
Overall conversion rule:
rule 1: the system components in the AADL model are mapped into engineering files named "system implementation names".
Rule 2: each process sub-component under the system component is mapped into a folder named "process implementation name" and placed in the system engineering file directory.
Rule 3: and placing the files generated by mapping the sub-components of all the process components in the folders generated by the rule 2.
Rule 4: the AADL data structure is converted into a specific data structure in the C language, and the generated data structure codes are stored in the gtypes.h file to be used as global variables.
Rule 5: all file and folder names in code generation are converted into lower case letters, and if the component names contain other characters, the lower case letters are converted into underlines in the C language.
The main functions of the kernel layer are to allocate partition resources and schedule partitions, including partition deployment files and kernel configuration files.
The partition deployment file comprises a deployment.h and a deployment.c, and mainly declares the type of the resource owned by the current partition, including time management of the partition, the communication type contained in the partition, the process number of the partition, the communication port ID in the partition and the like, and informs the system to provide corresponding services in a macro-definition mode.
Rule 6: because each partition of the IMA system is relatively independent, when the partition performs inter-partition communication, it is necessary to save the information of the partition, which mainly includes: partition name, partition port, etc. The system resource allocation refers to the resources of all the partitions, mainly including partition names, the number of communication ports of each partition, partition IDs, and the like. For example: ACoreOS653_CONFIG_NB_QUEUEINGS represents the number of queue communication ports in the partition, and the array ACoreOS653_buffers_names represents the buffer communication names in the partition.
The kernel configuration file module.xml of the IMA system mainly comprises the following four parts: partition basic information table, partition schedule table, inter-partition communication table and partition memory allocation table.
Rule 7: the partition basic information table mainly stores partition information and port information in the partition. The partition information mainly includes: partition ID, partition name, partition level, whether it is a system Partition, partition entry point, etc. correspond to the AADL's partition_ Identifier, partition _ Name, DAL, system _ Partition, initialize _Entry point, etc. attributes, respectively. The intra-partition port information mainly includes sampling ports and queue ports.
(1) Sampling port information generation rule
Rule 7-1: the data ports among the process components are mapped into sampling ports, and a sampling port information table T sampling (PortName, maxMessageSize, direction, refreshRateseconds). Each item in the table is a port name, a port size, a port direction, and a Sampling port Refresh time, respectively, wherein the Refresh time corresponds to a sampling_refresh_period attribute of AADL.
(2) Queue port information generation rule
Rule 7-2: mapping data event port attributes among process components into queue ports, and obtaining a queue port information table T Queuing (PortName, maxMessageSize, direction, maxNbMessages). Each item in the table is a port name, a port Size, a port direction, and a Queue Size, respectively, wherein the Queue Size corresponds to the queue_size attribute of the AADL.
Rule 8: the partition schedule mainly stores scheduling information of the partition. The scheduling framework comprises a model schedule T md (majorFrameseconds) and partition schedule T pn (Partitionldentifier，PartitionName，PeriodSeconds，PeriodDuationSeconds，Window_Schedule) A. The invention relates to a method for producing a fibre-reinforced plastic composite MajorFrameSeconds in the model schedule represents the total time frame length of the system. Each item in the partition schedule is partition ID, partition name, partition period, time slot of each partition, window schedule. PartitionID, partitionName, duration, module _schedule attributes of AADL respectively. The scheduling window is set according to specific scheduling information of the system.
Rule 9: the inter-partition communication table includes a source port information table and a destination port information table. Source Port information Table T source (PortNane, partitionName, partitionidentify), destination port information table T destination (PortName, partitionName, partitionIdentifier). And each parameter in the table is consistent, and the parameters respectively represent the port name, the partition name where the port is located and the partition ID.
Rule 10: the partitioned memory model is mapped into a partitioned memory table T mem (PartitionName, partitionIdentifier, memory_requirements, access). Each item in the Partition Memory table is a Partition name, a Partition ID, a Partition Memory Size, and a Memory read-write mode, and corresponds to attributes such as partition_ Name, partition _ Identifier, memory _size, memory_protocol, and the like of the AADL.
The partition and process of IMA correspond to the process component and thread component of AADL respectively, the method mainly focuses on the periodic process and aperiodic process of IMA, and corresponds to the periodic and aperiodic thread component of AADL. The AADL threads distinguish the types of threads according to the dispatch_protocol attribute: periodic represents a Periodic thread; aperiodic stands for Aperiodic thread.
Rule 11: the PROCESS initialization data structure process_attribute_type defined by the context operating system is shown below, and each item in the data structure represents a PROCESS name, a PROCESS entry point, a PROCESS stack size, a PROCESS base priority, a PROCESS period, a PROCESS time capacity, and a PROCESS deadline TYPE. The corresponding attributes are ThreadName, thread _ Entrypoint, stack _ Size, priority, period, time _ Capacity, deadline _type and the like of the thread components in AADL. And initializing the PROCESS_ATTRIBUTE_TYPE data structure by reading the corresponding periodic thread component information in the AADL.
Rule 12: the initialization data structure of the non-periodic PROCESS is also process_attribute_type, unlike periodic tasks, in AADL, the non-periodic thread structure has no periodic ATTRIBUTE, so PERIOD is typically set to negative or INFINITE_TIME_VALUE. The rest is similar to the periodic process. Acomos 653 provides APIs for suspend_self (SUSPEND non-periodic process currently executing), SUSPEND (SUSPEND specified non-periodic process other than itself), RESUME (release specified non-periodic process other than itself), and the like to operate on non-periodic process.
IMA partition communication is also an important task for system initialization, and is divided into inter-partition communication and intra-partition communication. The corresponding conversion methods will be described below, respectively.
The inter-partition communication has two modes of queue and sampling, and because the inter-partition communication at least involves more than two partitions, corresponding communication ports are required to be respectively created in the partitions of the two communication parties, wherein the port direction of a message sender is SOURCE, the port direction of a message receiver is DESTINATION, and the conversion rules of the message receiver are respectively described below.
Rule 13: queue communication uses a connection representation of event data PORTs between the process components of the AADL, mapped to a queue creation function create_queue_port of the antenna operating system, with parameter information as shown below. Wherein the input parameters of the function mainly comprise: queue PORT NAME queue_port_name, maximum MESSAGE byte number max_message_size of single MESSAGE, MESSAGE number max_nb_message that PORT MESSAGE queue can hold, PORT DIRECTION port_direction, queue_ DISCIPLINE when blocking. The port data type corresponds to the properties of PortName of AADL, the size of bytes occupied by the port data type, queue_ Size, directionType, queueing _Discipline and the like. The output parameters include: queue port ID, service interface execution state return_code. The send_queue_message function of the antenna operating system needs to be called for sending the queue MESSAGE, and the length of the queue MESSAGE does not exceed the maximum number of MESSAGE pieces. The operations of obtaining the queue PORT ID, checking the queue PORT state, receiving the MESSAGE and the like are needed to be sequentially executed when the MESSAGE is received, and the GET_QUEUING_PORT_ID function, the GET_QUEUING_PORT_STATUS function and the RECEIVE_QUEUING_MESSAGE function of the antenna operating system are sequentially called.
Rule 14: the SAMPLING communication uses a connection representation of the data PORTs between the process components of the AADL, mapped to a SAMPLING creation function create_sampling_port of the antenna operating system, the parameter list is shown below. Wherein the input parameters of the function mainly comprise: SAMPLE PORT NAME sample_port_name, maximum MESSAGE SIZE max_message_size of single MESSAGE, PORT direction_direct, SAMPLE PORT REFRESH rate refresh_period, and the like, which correspond to the attributes of AADL, such as PORT NAME of AADL, byte SIZE occupied by PORT data type, directionType, sampling _refresh_period, and the like, respectively. The output parameters include: sampling port ID, service interface execution state return_code. The sending of the SAMPLING MESSAGE requires the invocation of the write_sampling_message function of the antenna operating system, the receiving of the MESSAGE requires the sequential execution of operations such as obtaining the SAMPLING PORT ID, checking the SAMPLING PORT state, receiving the SAMPLING MESSAGE, and the like, and the sequential invocation of the get_sampling_port_id function, get_sampling_port_status function, and read_sampling_message function of the antenna operating system.
Intra-partition communication includes four modes of blackboard, buffer area, event and signal quantity, and is different from inter-partition communication in that intra-partition communication only needs to create a communication port in the affiliated partition. Their conversion rules are described below, respectively.
Rule 15: BLACKBOARD communication uses a data component representation shared between thread components in the same process of AADL or a data port representation connected between thread components located in the same process, mapped to a BLACKBOARD creation function create_black of the antenna operating system, the parameter list is shown below. Wherein the function input parameters include: BLACKBOARD NAME, BLACKBOARD maximum MESSAGE length MESSAGE SIZE of BLACKBOARD. The properties of PortName, port data type, and byte size of AADL are respectively corresponding. The output parameters include: blackboard port ID, service interface execution status return_code. Writing a message on a 'BLACKBOARD' requires calling a DISPLAY_BLACK BOARD function of a vein operation system, reading the 'BLACKBOARD' message requires sequentially executing operations of acquiring a BLACKBOARD port ID, checking a BLACKBOARD state, reading the BLACKBOARD message and the like, and sequentially calling a GET_BLACK BOARD_ID function, a GET_BLACK BOARD_STATUS function and a READ_BLACK BOARD function of the vein operation system.
Rule 16: BUFFER communication uses a connection representation of event data ports between thread members in the same AADL process, mapped to a BUFFER creation function create_buffer of the antenna operating system, the parameter list is shown below. Wherein the input parameters include: BUFFER NAME buffer_name, BUFFER maximum MESSAGE length max_message_size, maximum MESSAGE number max_nb_message contained in BUFFER, BUFFER queuing_ DISCIPLINE. The properties of PortName, the byte size occupied by the port data type, queue_ Size, queueing _Discipline and the like of the AADL are respectively corresponding. The output parameters include: buffer port ID, service interface execution state return_code. Sending the message to the BUFFER area requires calling the send_buffer function of the antenna operating system, receiving the BUFFER area message requires sequentially executing operations of obtaining the port ID of the BUFFER area, checking the state of the BUFFER area, receiving the BUFFER area message, and the like, and sequentially calling the get_buffer_id function, the get_buffer_status function and the receive_buffer function of the antenna operating system.
Rule 17: EVENT communication uses a connection representation of EVENT ports between thread members in the same AADL process, mapped to an EVENT port creation function create_event of the antenna operating system, the EVENT port creation function parameter list is shown below. Wherein the input parameters include: EVENT NAME event_name, portName attribute corresponding to AADL. The output parameters include: event port ID, service interface execution state return_code. Unlike other communication modes, the event port does not contain a data type, so when using event communication, a trigger event needs to be bound to the input event port, namely, a computer_entry attribute is added, and a trigger task of the event is specified. Setting an EVENT requires calling a SET_EVENT function of a vein operation system, accepting the EVENT requires sequentially executing operations such as obtaining an EVENT port ID, checking an EVENT state, obtaining a specified EVENT and the like, and sequentially calling a GET_EVENT_ID function, a GET_EVENT_STATUS function and a WAIT_EVENT function of the vein operation system.
Rule 18: the SEMAPHORE communication is represented using a data structure shared among a plurality of thread structures in the AADL process structure, mapped to a SEMAPHORE creation function create_semaphore of the antenna operating system. Unlike the blackboard communication using a data member, a Concurrency_control_protocol attribute defined at the data member is required to determine a Concurrency Control Protocol for shared data access when using the data member as a traffic communication. The parameter list of the function is shown below. Wherein the input parameters include: SEMAPHORE NAME semaphore_name, SEMAPHORE CURRENT VALUE current_name, SEMAPHORE MAXIMUM VALUE, queuing_ DISCIPILNE when a process is blocked. And the attributes such as PortName, queueing _Discipline and the like of the AADL are respectively corresponding. The current and maximum values of the semaphore are set according to the system resources, and are generally defaulted to 1. The output parameters include: the semaphore port ID, service interface execution state return_code. Releasing the SEMAPHORE requires calling the signal_SEMAPHORE function of the antenna operating system, acquiring the SEMAPHORE requires sequentially executing operations such as acquiring the SEMAPHORE port ID, checking the SEMAPHORE state, acquiring the designated SEMAPHORE, and the like, and sequentially calling the GET_SEMAPHORE_ID function, the GET_SEMAPHORE_STATUS function and the WAIT_SEMAPHORE function of the antenna operating system.
Rule 19: for AADL PERIODIC building blocks, the entry function uses a < thread name_ jod > naming, the cyclic process of the PERIODIC thread maps to the while (1) cycle of the entry function, and the PERIODIC WAIT maps to the PERIOCIC_WAIT () function of the antenna operating system, placed at the end of the while cycle. Table 3 is an example of a functional mapping of a periodic process.
Table 3 mapping examples of periodic processes
Rule 20: for AADL aperiodic thread building blocks, the entry function is named using < thread name_job >, the cyclic process of the aperiodic thread maps to the while (1) cycle of the entry function, the wait event triggers to map to the SUSPEND_SELF () function of the antenna operating system, and is placed at the end of the while cycle. Table 4 is an example of a mapping of non-periodic processes.
Table 4 mapping examples of aperiodic processes
The data types of the data structure are mapped to corresponding C language data types, and the data types are classified into simple data types and complex data types.
Rule 21: AADL simple data types map to C language base data types. The data identifier is converted into a corresponding C-language variable identifier. Table 5 is a mapping example of basic data types.
Table 5 basic type mapping examples
Rule 22: the AADL complex data structure maps to a structure in the C language. The data component name, the data subcomponent name and the data subcomponent type are mapped to a structure name, an internal member type. Table 6 is an AADL data structure conversion example.
Table 6 structural body map example
The task layer mainly generates functional behavior codes of the system, and the functional behavior of the system is expressed by subroutine components of AADL. Specific implementations of the subroutines may be represented by heterogeneous components such as SCADE, C, SDL. All subroutine code within the partition is automatically generated in the subbrogram.h and subbrogram.c files. The following mainly gives the subroutine and the code automatic generation rules of the data members.
Rule 23: the subroutine of AADL maps to a function in the C language, and the feature of the subroutine component translates to a list of parameters in the C language, the function name being < subroutine_subroutine name >. If the subroutine component is implemented in other languages, the corresponding algorithm is called to generate the C language, and the corresponding function is called in the generated C code. Wherein the out parameter of the subroutine component corresponds to the output parameter of the C language, and in parameter represents the input parameter of the C language. Table 7 is an AADL subroutine parameter mapping example.
Table 7 subroutine parameter mapping examples
5) Code bonding
According to the HMC4ACoreOS attribute set defined above, port mapping between AADL model and heterogeneous components is defined by interface_binding, and input port, output port and bidirectional port mapping are supported. The input and output parameters of the heterogeneous component are bound with the in parameter and out parameter attributes of the subroutine component, and meanwhile, the data type of the parameters is specified. And calling related subroutine sequences in the thread component, and connecting ports of the thread component with parameters of the subroutine component to realize calling related functional behaviors.
In the process of generating codes, firstly checking whether the port data types of the heterogeneous component parameters and the AADL are consistent, prompting corresponding errors if the port data types of the heterogeneous component parameters and the AADL are inconsistent, then checking whether the port directions of the AADL are consistent with the parameter directions of the heterogeneous component parameters, prompting corresponding errors if the port data types and the parameter directions of the heterogeneous component parameters are inconsistent, adding relevant data structure code references in function codes if the port data types and the parameter directions are not consistent with the parameter directions, adding the function code references in frame codes, namely calling relevant function functions in corresponding process loop bodies, transmitting input ports of the AADL to a designated heterogeneous model in a parameter mode, and transmitting results returned by the heterogeneous model to output ports of the AADL, wherein the input parameters are transmitted by using values, and the output parameters are transmitted by using addresses.
Claims (5)
1. A method for automatically generating a comprehensive avionics system security code for a weather operating system is characterized by comprising the following steps of: the method comprises the following steps:
step 1: according to AADL ARINC653 accessory requirements, expressing software and hardware information of an IMA system by adopting AADL and expressing functional behaviors of the IMA system by heterogeneous components to obtain an IMA model;
step 2: analyzing the IMA model through an AADL analysis module, converting model information into an abstract syntax tree and instantiating to obtain a model instance syntax tree;
step 3: defining corresponding conversion rules according to requirements of an API manual of a vein operation system, expressing the conversion rules by using a Stringtemplate template engine, and generating corresponding template files;
step 4: extracting key information from the model instance grammar tree according to the conversion template and the safety coding requirement, and generating a configuration file from the key information; converting the model instance grammar tree into a C language grammar tree, generating corresponding frame codes and data structure codes, and converting heterogeneous components into corresponding functional codes;
step 5: bonding the generated frame codes, the data structure codes and the functional codes to obtain executable codes facing the antenna operating system;
The step 2 specifically comprises the following steps:
instantiating an IMA model to generate an AAXL2 file of a top-level system;
analyzing the AAXL2 file through an AADL analysis module to obtain a system instance SystemInstanceImpl; traversing the system instance class SystemInstanceImpl to obtain subcomponents of the system instance class, including a process component, a memory component and a processor component; traversing the process component to obtain a thread component and a data component; traversing layer by layer until the sub-component information of the component is empty or does not comprise the sub-component;
converting the traversed model information into an abstract syntax tree;
adding concrete attribute information for each node on the basis of the abstract syntax tree to obtain a model instance syntax tree;
the step 4 specifically comprises the following steps:
traversing the model instantiation grammar tree, extracting node component information, and respectively generating corresponding C codes according to the conversion template and the safety coding requirement;
the method comprises the steps that a kernel layer of IMA generates a system configuration file and a partition configuration file, wherein the system configuration file comprises partition ports, partition memories, partition scheduling and inter-partition communication; the partition configuration file comprises the number of tasks in the partition, the number of communication ports and intra-partition communication;
the partition layer of IMA generates a frame code and a data structure code, wherein the frame code file comprises main.c, activity.h, activity.c, global.h and global.c; the main.c file comprises inter-partition communication port creation, intra-partition communication port creation, process resource allocation, process creation and process starting; the activity.h and activity.c files comprise intra-partition communication, inter-partition communication, periodic process scheduling and non-periodic process scheduling; the global.h file and the global.c file include global variable and global function information; the data structure code file comprises gttypes.h and gttypes.c, and the data structure code file comprises a data structure code of the AADL data component conversion generation C;
The task layer of IMA generates functional codes, which comprise a substrogram.h file and a substrogram.c file, and calls a corresponding algorithm to generate C codes according to the types of heterogeneous components, and if the heterogeneous components are the C codes, the corresponding C code files are directly referenced, and a corresponding function is called.
2. The method for automatically generating the security code of the integrated avionics system for the antenna operating system according to claim 1, wherein the method comprises the following steps of: the step 1 specifically comprises the following steps: according to AADL ARINC653 accessory requirements, adopting an AADL software component to express the middle partition, the process, inter-partition communication, intra-partition communication, memory and modes of the IMA system;
expressing the functional behavior of the IMA system through heterogeneous components, expanding an AADL attribute set, and creating an HMC4ACore OS attribute set to support connection of an AADL model and a heterogeneous model;
the HMC4 acoeos attribute set includes: attribute parameters_connections, attribute parameters_binding, attribute file_path, attribute source_language, attribute supported_source_language, and attribute source_name;
the attribute parameter_connections is used for describing connection of the AADL port and heterogeneous component parameters; the attribute parameter_binding is used for describing the Binding of the AADL port and the heterogeneous component Parameter; the attribute File_Path is used for describing heterogeneous component File paths, the attribute Source_Language is used for describing the realization Language of heterogeneous components, the attribute supported_Source_Languages is used for describing the realization Language of Supported heterogeneous components, and the attribute Source_Name is used for describing the function names or method names of heterogeneous components.
3. The method for automatically generating the security code of the integrated avionics system for the antenna operating system according to claim 1, wherein the method comprises the following steps of: step 3, specifically comprising:
defining conversion rules from an AADL model to a C code and conversion rules from the AADL model to a configuration file according to AADL ARINC653 accessory requirements and requirements of an API manual of a vein operation system;
and expressing the mapping of the conversion rule from the AADL model to the C code and the mapping of the conversion rule from the AADL model to the configuration file by adopting a Stringtemplate template engine to obtain a template file.
4. A method for automatically generating a security code for a comprehensive avionics system for a antenna operating system according to claim 3, wherein: the mapping of the conversion rule from the AADL model to the C code and the mapping of the conversion rule from the AADL model to the configuration file expressed by adopting the Stringtemplate template engine comprise the following steps:
rule 1: mapping system components in the AADL model into engineering files named by system realization names;
rule 2: mapping each process sub-component under the system component into a folder named by a process realization name, and placing the folder in an engineering file directory;
rule 3: placing the files generated by mapping the sub-components of all the process components in folders named by process realization names;
Rule 4: converting the data component into a specific data structure in the C language, and storing the generated data structure code in a gtypes.h file as a global variable;
rule 5: in the code generation process, all file names and folder names are converted into lowercase letters, and if the component names contain other characters, the lower-case letters are converted into underlines in the C language;
rule 6: when inter-partition communication is performed, partition information is stored, the partition information including: partition name, number of processes in a partition, number of communication ports of each partition, and partition communication port ID;
rule 7: the kernel configuration file of the IMA system includes: partition basic information table, partition schedule table, inter-partition communication table and partition memory allocation table;
the partition basic information table is adopted to store partition information and port information in the partition; the partition information mainly includes: partition ID, partition name, partition level, whether it is a system partition and partition entry point; partition ID, partition Name, partition level, whether the System Partition and Partition entry point are the attribute partition_identifier, attribute partition_name, attribute DAL, attribute System_partition and attribute initialization_Entry_Point of the corresponding AADL respectively; the partition port information comprises a sampling port and a queue port;
Rule 8: using a partition schedule T pn The method comprises the steps of (Partification, partitionName, periodSeconds, periodDuationSeconds, window_Schedule) saving scheduling information of partitions, wherein Partification is partition ID, partitionName, periodSeconds is partition period, periodDuationSeconds is time slot of each partition, window_Schedule is Window scheduling, partitionldentifier, partitionName, periodSeconds, periodDuationSeconds corresponds to AADL attribute Partification ID, attribute Partification name, attribute Duration, attribute Module_Schedule respectively, and scheduling Window is set according to specific scheduling information of a system;
rule 9: the inter-partition communication table comprises a source port information table T source (PortNane, partitionName, partitionidentify) and destination port information table T destination (PortName, partitionName, partitionIdentifier) PortName represents the port name, partification Name represents the partition name where the port is located, partification represents the partition ID;
rule 10: the partitioned memory model is mapped into a partitioned memory table T mem (PartitionName, partitionIdentifier, memory_requirements, access), partification Name represents Partition Name, partification represents Partition ID, memory_requirements represents Partition Memory Size, access represents Memory read/write mode, and the Partification_requirements, partification_size, and Partification_protocol correspond to the attribute Partification_name, partification_Idtification_size, and Partification_protocol of AADL, respectively;
Rule 11: a PROCESS defined by the antenna operating system initializes a data structure process_attribute_type, comprising: PROCESS NAME process_name_type, PROCESS entry point system_address_type, PROCESS STACK SIZE stack_size_type, PROCESS base priority_type, PROCESS period system_time_type, PROCESS TIME capacity system_time_type, PROCESS DEADLINE TYPE deadline_type, threadName, thread _ Entrypoint, stack _ Size, priority, period, time _ Capacity, deadline _type, respectively corresponding to thread members in AADL; initializing a PROCESS_ATTRIBUTE_TYPE data structure by reading the corresponding periodic thread component information in the AADL;
rule 12: the initialization data structure of the non-periodic PROCESS is the same as process_attribute_type, wherein system_time_type is set to negative or INFINITE_time_value;
rule 13: queue communication uses a connection representation of event data PORTs between AADL's process components mapped to a queue creation function create_queue_port of the antenna operating system, comprising: queue PORT NAME queue_port_name, maximum MESSAGE byte number max_message_size of single MESSAGE, MESSAGE byte number max_nb_message that PORT MESSAGE Queue can hold, PORT DIRECTION port_direct, queue-while-blocking principle queue_ DISCIPLINE, PORT NAME corresponding to AADL, PORT data type occupied byte SIZE, queue_ Size, directionType, queueing _discipline, respectively;
The queue creation function create_queue_port further includes: queue PORT ID queue_port_id, service interface execution state return_code; the send_queue_message function of the antenna operating system needs to be called by sending the queue MESSAGE; the received MESSAGE needs to execute the acquisition queue PORT ID, check the queue PORT state and RECEIVE the MESSAGE in sequence, and call the GET_QUEUING_PORT_ID function, the GET_QUEUING_PORT_STATUS function and the RECEIVE_QUEUING_MESSAGE function of the antenna operating system in sequence;
rule 14: the SAMPLING communication uses a connection representation of data PORTs between process components of AADL, mapping to CREATE a function create_sampling_port for the antenna operating system, comprising: SAMPLE PORT NAME sample_port_name, maximum MESSAGE SIZE max_message_size of single MESSAGE, PORT direction_direct, SAMPLE PORT REFRESH rate refresh_period, PORT NAME of AADL, byte SIZE occupied by PORT data type, directionType, sampling _refresh_period, respectively;
the sample creation function create_sample_port further includes: sample PORT ID SAMPLING _port_id, service interface execution state return_code; sending a SAMPLING MESSAGE to call a write_sampling_message function of the antenna operating system, and sequentially executing the steps of acquiring a SAMPLING PORT ID, checking the SAMPLING PORT state and receiving the SAMPLING MESSAGE by the receiving MESSAGE, and sequentially calling a GET_sampling_PORT_ID function, a GET_sampling_PORT_status function and a READ_sampling_message function of the antenna operating system;
Rule 15: intra-partition communication includes blackboard communication, buffer communication, event communication, and semaphore communication;
BLACKBOARD communication uses a data component representation shared between thread components in the same process of AADL or a data port representation connected between thread components located in the same process, mapped to a BLACKBOARD creation function create_black box of the antenna operating system, comprising: the BLACKBOARD NAME blackboad_name and the BLACKBOARD maximum MESSAGE length message_size of the BLACKBOARD correspond to the SIZEs of the bytes occupied by the PortName and the port data type of the AADL respectively;
the BLACKBOARD creation function create_blackboard of the antenna operating system further includes: BLACKBOARD port blackbord_id, service interface execution state return_code; writing a message on a BLACKBOARD requires calling a DISPLAY_BLACK BOARD function of a vein operation system, reading the BLACKBOARD message requires sequentially executing the steps of acquiring a BLACKBOARD port ID, checking a BLACKBOARD state and reading the BLACKBOARD message, and sequentially calling a GET_BLACK BOARD_ID function, a GET_BLACK BOARD_STATUS function and a READ_BLACK BOARD function of the vein operation system;
rule 16: BUFFER communication using a connection representation of event data ports between thread members in the same AADL process, a BUFFER creation function create_buffer mapped to the antenna operating system, comprising: BUFFER NAME buffer_name, maximum MESSAGE length max_message_size of BUFFER, maximum MESSAGE number max_nb_message contained in BUFFER, BUFFER QUEUING rule queue_ DISCIPLINE, corresponding to port NAME of AADL, byte SIZE occupied by port data type, queue_ Size, queueing _dispapline, respectively;
The BUFFER creation function create_buffer further includes: BUFFER port ID buffer_id, service interface execution state return_code; sending a message to a BUFFER area requires calling a send_buffer function of a vein operation system, receiving the BUFFER area message requires sequentially executing the steps of obtaining a BUFFER area port ID, checking a BUFFER area state and receiving the BUFFER area message, and sequentially calling a GET_buffer_ID function, a GET_buffer_status function and a RECEIVE_buffer function of the vein operation system;
rule 17: EVENT communication uses a connection representation of EVENT ports between thread members in the same AADL process mapped to an EVENT port creation function create_event of the antenna operating system, comprising: EVENT NAME event_name, portName attribute corresponding to AADL;
the EVENT port creation function create_event further includes: EVENT port ID event_id, service interface execution state return_code; binding a trigger event at an input event port by adding a Compute_Entry Point attribute while communicating using an event; setting an EVENT to call a SET_EVENT function of a vein operation system, and accepting the EVENT to sequentially execute the steps of acquiring an EVENT port ID, checking an EVENT state and acquiring a specified EVENT, and sequentially calling a GET_EVENT_ID function, a GET_EVENT_STATUS function and a WAIT_EVENT function of the vein operation system;
Rule 18: the SEMAPHORE communication is represented using a data structure shared among a plurality of thread structures in an AADL process structure, mapped to a SEMAPHORE creation function create_semaphore of a context operating system, comprising: SEMAPHORE NAME semaphore_name, SEMAPHORE CURRENT VALUE current_name, SEMAPHORE MAXIMUM VALUE, queuing_ DISCIPILNE, SEMAPHORE _name and queuing_ DISCIPILNE correspond to PortName, queueing _dispaline of AADL, respectively; the current value and the maximum value of the signal quantity are set according to system resources;
the SEMAPHORE creation function create_create further comprises: the SEMAPHORE port ID setup_id and the service interface execution state return_code;
when the signal volume communication uses the data component as the signal volume communication, the Concurrency_control_protocol attribute of the data component needs to be defined to determine the Concurrency Control Protocol of the shared data access;
releasing the SEMAPHORE requires calling a signal_SEMAPHORE function of the antenna operating system, acquiring the SEMAPHORE requires sequentially executing a SEMAPHORE port ID acquisition, SEMAPHORE state checking and designated SEMAPHORE acquisition, and sequentially calling a GET_SEMAPHORE_ID function, a GET_SEMAPHORE_STATUS function and a WAIT_SEMAPHORE function of the antenna operating system;
Rule 19: for AADL PERIODIC components, the entry function uses < thread name_ jod > naming, the cyclic process of the PERIODIC thread is mapped into a while (1) cycle of the entry function, the PERIODIC waiting is mapped into a PERIOCIC_WAIT () function of the antenna operating system, and the PERIODIC waiting is placed at the end of the while cycle;
rule 20: for AADL aperiodic thread components, the entry function is named with < thread name_job >, the cyclic process of the aperiodic thread is mapped into a while (1) cycle of the entry function, the waiting event trigger is mapped into a SUSPEND_SELF () function of the antenna operating system, and the waiting event trigger is placed at the end of the while cycle;
rule 21: the AADL simple data types are mapped to the C language basic data types; converting the data identifier into a corresponding C language variable identifier;
rule 22: the AADL complex data structure is mapped into a structural body of C language, and the data component name, the data subcomponent name and the data subcomponent type are mapped into the structural body name, the internal member name and the internal member type;
rule 23: the subroutine of AADL is mapped into the function in the C language, the characteristic of the subroutine structural element is converted into the parameter list in the C language, the function name is < subroutine_subroutine name >; if the subroutine component is realized by other languages, calling a corresponding algorithm to generate a C language, and calling a corresponding function in the generated C code, wherein an out parameter of the subroutine component corresponds to an output parameter of the C language, and in parameter represents an input parameter of the C language.
5. The method for automatically generating the security code of the integrated avionics system for the antenna operating system according to claim 1, wherein the method comprises the following steps of: the step 5 specifically comprises the following steps:
s510: checking whether the port data types between the AADL model and the heterogeneous components are matched, if so, jumping to S520, otherwise, prompting type error information;
s520: checking whether the port direction of the AADL model is matched with the parameter direction of the heterogeneous component, if so, jumping to S530, otherwise, prompting direction error information;
s530: and adding related data structure code references in the function codes, and adding the function code references in the frame codes to obtain the executable codes oriented to the antenna operating system.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211421963.XA CN116048518B (en) | 2022-11-14 | 2022-11-14 | Automatic generation method of comprehensive avionics system security codes for antenna operating system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211421963.XA CN116048518B (en) | 2022-11-14 | 2022-11-14 | Automatic generation method of comprehensive avionics system security codes for antenna operating system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116048518A CN116048518A (en) | 2023-05-02 |
| CN116048518B true CN116048518B (en) | 2023-12-01 |
Family
ID=86131974
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211421963.XA Active CN116048518B (en) | 2022-11-14 | 2022-11-14 | Automatic generation method of comprehensive avionics system security codes for antenna operating system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116048518B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117056236B (en) * | 2023-10-10 | 2024-01-30 | 卡斯柯信号(北京)有限公司 | Safety variable verification method and device for rail transit signal software |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101807147A (en) * | 2010-04-15 | 2010-08-18 | 西北工业大学 | Method for automatically abstracting software architecture from embedded software code |
| CN104932905A (en) * | 2015-07-14 | 2015-09-23 | 北京神舟航天软件技术有限公司 | Automatic code generation method from AADL to C language |
| CN105608247A (en) * | 2015-11-11 | 2016-05-25 | 北京航空航天大学 | IMA resource security analysis-oriented AADL to ECPN model conversion method |
| CN109558117A (en) * | 2018-10-19 | 2019-04-02 | 南京航空航天大学 | The C code automatic generation method of the refinement of AADL model and its support towards AEROSPACE APPLICATION |
| CN109634600A (en) * | 2018-10-30 | 2019-04-16 | 西安电子科技大学 | A kind of code generating method based on security extension SysML and AADL model |
| US10261760B1 (en) * | 2013-12-05 | 2019-04-16 | The Mathworks, Inc. | Systems and methods for tracing performance information from hardware realizations to models |
| CN112114801A (en) * | 2020-09-02 | 2020-12-22 | 南京航空航天大学 | IMA-oriented AADL multi-paradigm modeling and C code automatic generation method |
| CN113626026A (en) * | 2021-07-21 | 2021-11-09 | 北京理工大学 | Code generation method supporting complex model structure conversion |
| CN114756213A (en) * | 2022-06-14 | 2022-07-15 | 军事科学院系统工程研究院网络信息研究所 | Automatic code generation method and device for intelligent control system |
-
2022
- 2022-11-14 CN CN202211421963.XA patent/CN116048518B/en active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101807147A (en) * | 2010-04-15 | 2010-08-18 | 西北工业大学 | Method for automatically abstracting software architecture from embedded software code |
| US10261760B1 (en) * | 2013-12-05 | 2019-04-16 | The Mathworks, Inc. | Systems and methods for tracing performance information from hardware realizations to models |
| CN104932905A (en) * | 2015-07-14 | 2015-09-23 | 北京神舟航天软件技术有限公司 | Automatic code generation method from AADL to C language |
| CN105608247A (en) * | 2015-11-11 | 2016-05-25 | 北京航空航天大学 | IMA resource security analysis-oriented AADL to ECPN model conversion method |
| CN109558117A (en) * | 2018-10-19 | 2019-04-02 | 南京航空航天大学 | The C code automatic generation method of the refinement of AADL model and its support towards AEROSPACE APPLICATION |
| CN109634600A (en) * | 2018-10-30 | 2019-04-16 | 西安电子科技大学 | A kind of code generating method based on security extension SysML and AADL model |
| CN112114801A (en) * | 2020-09-02 | 2020-12-22 | 南京航空航天大学 | IMA-oriented AADL multi-paradigm modeling and C code automatic generation method |
| CN113626026A (en) * | 2021-07-21 | 2021-11-09 | 北京理工大学 | Code generation method supporting complex model structure conversion |
| CN114756213A (en) * | 2022-06-14 | 2022-07-15 | 军事科学院系统工程研究院网络信息研究所 | Automatic code generation method and device for intelligent control system |
Non-Patent Citations (5)
| Title |
|---|
| A Method of Automatic Code Generation Based on AADL Model;Chen Zhang 等;《Proceedings of the 2018 2nd International Conference on Computer Science and Artificial Intelligence》;180–184 * |
| C2AADL_Reverse: A model-driven reverse engineering approach to development and verification of safety-critical software;Zhibin Yang 等;《Journal of Systems Architecture》;第118卷;第1-10页 * |
| 基于AADL的嵌入式安全规范代码生成研究与实现;章文炳;《中国优秀硕士学位论文全文数据库 信息科技辑》(第2期);I137-127 * |
| 基于ARINC653平台的AADL模型代码自动生成技术研究;魏峰;《中国优秀硕士学位论文全文数据库 信息科技辑》(第3期);I138-3094 * |
| 面向IMA的AADL多范式建模及代码自动生成方法;邱宝 等;《小型微型计算机系统》;第42卷(第10期);2223-2233 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116048518A (en) | 2023-05-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Mubeen et al. | Supporting timing analysis of vehicular embedded systems through the refinement of timing constraints | |
| Feiler et al. | The SAE Architecture Analysis & Design Language (AADL) a standard for engineering performance critical systems | |
| Martin et al. | Embedded UML: a merger of real-time UML and co-design | |
| US6226692B1 (en) | Method and system for constructing software components and systems as assemblies of independent parts | |
| CN108196827B (en) | Automatic conversion method from non-formalized requirement specification template to formalized design model | |
| KR101795844B1 (en) | Runtime system | |
| CN109558117B (en) | Aerospace application-oriented AADL model refinement and C code automatic generation method supported by same | |
| CN110597498B (en) | AADL model refinement method and Ada executable code automatic generation method supported by same | |
| CN112114801B (en) | IMA-oriented AADL multi-paradigm modeling and C code automatic generation method | |
| CN116048518B (en) | Automatic generation method of comprehensive avionics system security codes for antenna operating system | |
| Bucaioni et al. | A metamodel for the Rubus component model: extensions for timing and model transformation from EAST-ADL | |
| Roychoudhury | Embedded systems and software validation | |
| CN111176658B (en) | Automatic conversion method from AADL (architecture analysis and design language) to Simulink model based on meta-object mechanism | |
| Thomas et al. | Software real-time resource modeling | |
| CN111338638A (en) | System and method for realizing automatic generation of communication between embedded software components | |
| CN110874213A (en) | Runtime type extension and reflection method of static strong type language | |
| Penninckx et al. | Abstract I/O Specification | |
| Hagge et al. | Applying the handler-based execution model to IEC 61499 basic and composite function blocks | |
| Hu et al. | Safety critical applications and hard real-time profile for Java: a case study in avionics | |
| Wang et al. | Automatic RT-Java code generation from AADL models for ARINC653-based avionics software | |
| Schade et al. | Automatic Deployment of Embedded Real-time Software Systems to Hypervisor-managed Platforms | |
| Chen et al. | Do no harm: Model checking ehome applications | |
| Yang et al. | Model-based design and verification of automotive electronics compliant with OSEK/VDX | |
| Correa et al. | Verification based development process for embedded systems | |
| Luckcuck | Safety-Critical Java Level 2: Applications, Modelling, and Verification |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |