The article discusses the architectural basis of the cross-platform onboard software for navigation and communication satellites. The functional characteristics of the designed software components are the queues used, the ports, the supported hardware, and the low-level inter-hardware communication protocols. The verbal description of the selected area of knowledge and the formalization of relations between individual entities allows you to move from the architectural basis, limited by physical parameters and the environment for the functioning of software tools, to a descriptive model, which served as the basis for a relational database. An identification method is proposed for unambiguously identifying a specific component of the on-board software with the possibility of performing further actions on it, for example, archiving, retrieving, duplicating, etc. An onboard software component is viewed as a complex entity that contains not only program code, but also a number of attributes that are used during operation. The structural diagram of a relational database is presented. This structure unites and links both information about software components and the electronic document management tool as a whole.
The purpose of the developed identification method is to unambiguously determine a specific
component of the on-board software (OBS) for the possibility of further actions on it (archiving,
retrieval, duplication, etc. [
There are several options for identifying the program code that can be used in the process of searching for development objects for the cross-platform OBS of navigation communication satellites: information extraction (IE); parsing of program code; the method of labeling; building the atomic structure of the project.
Information extraction (IE) is an applied direction in the field of computational linguistics, which
studies the tasks of extracting certain information from natural language (NL) texts - terms and their
relations, events and named entities (names, personalities, geographical names), etc. [
The solution of such problems requires the recognition of certain linguistic structures (for example,
noun phrases) in the text, which is usually implemented on the basis of partial parsing, without full
parsing of sentences of the text. The construction of specific AI applications is most often performed
using specialized instrumental systems [
Template languages used in instrumental systems for building NL-applications have a number of problems that complicate their effective use.
When constructing the internal representation of the text, it is first broken up into fragments - words,
punctuation marks and whitespace characters, and a morphological analysis of words is performed, the
morphological (syntactic) interpretations of which form the edges of the graph. In this case, in the
general case, a pair of adjacent vertices of the graph are connected by several edges due to
morphological homonymy (for example, the nominative and accusative cases of nouns). For any
structure highlighted in the text, its syntactic interpretation is represented in the text graph by an
additional edge [
The considered graphical representation of the text is convenient for taking into account various combinations of morphological interpretations of words included in the text and allows, when imposing templates, to uniformly process both word elements and auxiliary templates. Selection of a structure using the LSPL (Lexico-Syntactic Pattern Language) pattern is a search in a text graph, which includes three main stages.
Step 1. The set of edges from which the search can be started is determined; for this, the indexes of words, patterns and parts of speech are used (these indexes are built simultaneously with the construction of the text graph).
Step 2. Paths starting from found edges and corresponding sequences of template elements are defined in the graph. The search for these paths represents a depth-first traversal of the graph with a backward step, while at each step all admissible path extensions are considered that correspond to the current element of the template and the restriction on morphological characteristics specified for it. The conditions for matching elements are checked immediately after specifying morphological characteristics, which makes it possible to reduce the set of considered paths in the graph.
Step 3. The found paths are grouped together to form overlay variants that are added to the graph as new edges. The grouping of paths is carried out for more efficient operation of the method.
For the analysis, a software component was used, developed by the authors within the framework of the project "Technology for organizing the life cycle of cross-platform software for onboard equipment for unmanned aerial vehicles" (Reg. No. R&D AAAA-A17-117041910158-8).
The very structure of the handler scanner might look like this: #include <fstream> #include <iostream> #include <string> #include "FlexLexer.h" std::string tmpstr; int main(int argc, char* argv[]) { if (argc < 2) { std::cout << "USE: ccflexscan <source file>" return 0;
}
std::ifstream infile(argv[
When applying it, observing the conditions of the syntax and the rules of the dictionary, at the output we will receive a list of the following content:
Read ' RUN ' (token values is 286) Read ' OPTIMIZATION ' (token values is 283)
The multiplicity of syntactic interpretations of one piece of text inherent in natural language inevitably increases the search space and the amount of memory required to store a graph of text. This is especially noticeable when the template contains a large number of elements that do not participate in the matching conditions, and also includes repetitions of elements without their matching.
Parsing (often called parsing in computer science) is a technology for automatically collecting data based on a given attribute.
The information retrieved by parsers (parsers) is accumulated for the purpose of selection according to certain criteria, analysis of dynamics, backup storage in case of loss of access to primary sources, and is also used for cataloging.
The separation of the necessary information occurs through the syntactic and lexical analysis of its content. This process is called parsing. Parsing is part of many information processing processes, from translating text to translating high-level language code into machine code.
Parsers are most actively used in the processing of Internet pages by search engine algorithms. But parsing is also used for solving less global problems, for example - parsing is used by programs to automatically check the uniqueness of text information, quickly comparing the content of hundreds of web pages with the proposed text. Parsing can also be used to automatically search for information, for example, to fill in the fields of characteristics of hardware, sensors, etc.
As an example of a tool for analyzing program code, we present the following program: #include <stdio.h> #include <string> extern FILE *yyin, *yyout; // referenced from flex-generated scanner extern int yylineno; extern std::string tmpstr; int yylex(); int main(int argc, char* argv[]) { yyin = fopen("test.txt","r"); //yyout will ptr to stdout int iRes = 0; while ((iRes = yylex()) > 0) { //read something useful from file printf ("Read ‘%s’ (token values is %d) at
line %d\n",tmpstr.c_str(), iRes, yylineno); } printf ("Scanner return %d code\n",iRes); return 0; }
Its functions are similar to the program described in section 2 above, but the execution speed is lower, but this method has also proved to be an effective analysis tool.
As an intermediate result, we can conclude that the existing methods of parsing program code do not meet the requirements stated at the beginning - storage and retrieval of metadata, the possibility of hierarchical linking of components and memory of the final structure of projects as one of the elements of flexible search. To meet all the requirements for storing and retrieving useful information about the project, it is proposed to create a new identification method based on deterministic metadata.
At the stage of forming the basic description of the area of knowledge - the software components of the cross-platform OBS of communication and navigation satellites, the requirements for the description of the principles of functioning and the limitations of the physical environment of functioning were determined and formalized, such as: ensuring the operation of the power system, voltage level, board, etc.
In general, this will allow us to carry out effective identification of software components, since the presented restrictions and requirements can act as metadata that uniquely describe a specific component.
The architectural basis of the cross-platform OBS of navigation communication satellites (Figure 2)
is presented in [
The resulting verbal description of the selected area of knowledge and the formalization of relations between individual entities made it possible to move from an architectural basis, limited by physical parameters and the environment for the functioning of software, to a descriptive model that served as the basis for a relational database. 4.1.
the cross-platform OBS being developed. These informational attributes are typical for both applied and executive software. because from the point of view of the programmer there is no fundamental difference in the development of a software component. When designing a component, it should be noted that a separate software function in the future can be used both as an independent component and as one of the versions of the multiversion pool. Technically, there is no difference between the development of one of the versions of the multiversion pool and a separate software component, since they will be executed in the same way as a FreeRTOS stream, and a separately developed module - the decision block - is responsible for the functionality of the multiversion execution.
Let's consider an example of a software module for processing readings of a digital temperature sensor.
Design Reference (Component): This module must be connected to an Analog Devices ADT7318 Digital Temperature Sensor or equivalent. The sensor output is connected to DIO pin 5 on the board. The module must poll the sensor every 2000ms, calculate the temperature value in Celsius and Fahrenheit. The temperature value in Celsius is placed in the xQueueCTemp () queue. The temperature value in Fahrenheit is placed in the xQueueFTemp () queue.
The task itself is an element of electronic document management and is stored in the database in the form of a document signed with an electronic signature. Inside the document, there is also metainformation for the unambiguous definition of the parameters of the developed software block and is used to create the "skeleton" of the project. The metadata related to the design assignment for the temperature sensor readings processing module are given below (Table 1 ). Supported hardware ADT7318 digital temperature sensor or equivalent. The range of input values is presented in Table 5
Table 5
Port / Queue
DIO5
The metadata themselves uniquely identify the block when searching for information through the database, and also serve as keys for searching for block variants close to the criteria.
Storage order for later retrieval. To break many-to-many data, intermediate tables are used, in which two foreign keys of the tables being linked are used as the primary key of the table itself.
Table 6 is an example of a table for breaking a many-to-many relationship.
Table 6 Example of the relationship queue_id modules_id 101 1 101 2 101 3 i/o 1 1 0
Since the primary keys are the id of the queue and the id of the module, a many-to-many relationship is formed when the tables are directly linked. To break this connection, an intermediate table is used, which also serves to facilitate the process of finding the necessary information. As a request, let's try to find out which modules work with the queue at index 101.
Figure 3 shows the following tables:
Table 1 . The modules entity serves as a repository of the main attributes of the components being developed and the platform, modules_status, users "dictionaries" are connected to it.
Table 2 . The docs entity serves as a repository of data about the elements of the electronic document management system, the “dictionaries” docs_type, docs_status, users are connected to it.
Also, in the environment of electronic document management, database objects can be created, retrieved and modified by means of the PHP language. Below is an example of a script that generates a report on the stage of module readiness.
<? if (!is_numeric($rank) || $rank <= 0) {header("Location: ./check.php"); die; } $mods_status=[ "<span style='color:gray;'>Indeveloping</span>", "<span style='color:pink;'> Readytotest</span>", "<span style='color:blue;'> Ontesting </span>",
"<spanstyle='color:red;'> Submitted for revision </span>", "<span style='color:green;'> Ready</span>"]; if (!$_GET[id]){ echo "<table border=0 width=100% class='docs-table'>"; echo "<tr><th width=30px>Ver</th><th>Modulename</th><th>Status</th><th>Author</th> <th>Data</th></tr><tr><td colspan=5><hr></td></tr>";
$q_mod_all=mysqli_query($link, "SELECT * FROM `modules` ORDER BY date DESC"); for ($c=0; $c<mysqli_num_rows($q_mod_all); $c++) { $new='normal'; $mods = mysqli_fetch_array($q_mod_all);
if ($mods['creater']==$user['id']) $author=$user['f']." ".substr($user['i'],0,2).". ".substr($user['o'],0,2).". ";
else { $creater=mysqli_fetch_array(mysqli_query($link, "SELECT `f`,`i`,`o` FROM `users` WHERE id='{$mods['creater']}' LIMIT 1")); $author=$creater['f']." ".substr($creater['i'],0,2).". ".substr($creater['o'],0,2).". "; } echo "<tr style='font-weight:{$new}' onMouseMove=(this.style.background='#EBF4FD') onMouseOut=(this.style.background='white')> <td>".$mods[ver]."</td> <td onClick=(document.location.href='?act=modules&id=".$mods['id']."')>" .$mods[title]." ::</td> <td>".$mods_status[$mods['status']]."</td>
<td>".$author."</td> <td>".date('d.n.Y',$mods['date'])."</td>
</tr><tr><td
colspan=5><hr></td></tr>";
}
echo "</table>";
} else {
//echo "<div class=noprint><a
class=btnsaleonClick='window.print() ;'>Print</a></div>";
href='#'
$mod=mysqli_fetch_array(mysqli_query($link,
`modules` WHERE id=".intval($_GET[id]).""));
$author=author($mod, intval($_GET[id]));
$stack_in=explode("=>", $mod[stack])[0];
$stack_out=explode("=>", $mod[stack])[
FROM echo "<tr><td><h3>{$mod[title]}</h3>{$mod[date]}, {$author}, {$mods_status[$mod[status]]}<br></td></tr>"; echo "<tr><td><h3> description</h3>{$mod[info]}<br></td></tr>"; echo "<tr><td><h3>Inputqueues: </h3>{$stack_in}<br></td></tr>";
echo "<tr><td><h3>Outqueues: </h3>{$stack_out}<br></td></tr>"; if ($mod[status]==4) {
//$test=mysqli_fetch_array(mysqli_query($link, "SELECT * FROM `docs` WHERE type=pid=".intval($_GET[id]).""));
echo "<tr><td><h3>Test results:</h3><a href='#'>Test report</a><br></td></tr>";
echo "<div class=noprint><a class=btnsaleonClick='#'> Archive</a></div>"; } echo "<tr><td><h3> Programcode:</h3><br></td></tr>"; echo "</table>"; //echo "<div href='?act=modules&id={$mod['id']}' Newmodulebasedoncurrent</a></div>"; //echo $mod[link]; $file= file_get_contents("./modules/{$mod[link]}.txt"); ?>
Thus, the obtained scheme of interactions within a relational database will allow efficiently performing functional identification both in the form of SQL queries and third-party tools, if necessary.
In the process of developing the components of the cross-platform onboard software, their functional attributes will be entered into the database. According to these attributes, it becomes possible in the future to perform functional identification of the required module. Let's consider an example of functional identification of a component based on specified parameters.
These parameters are input / output queues (their IDs), platform selected, author, etc. In general, the set of attributes should be a strict filter list that filters out mismatched base lines. If a strict search did not give the necessary results, then a flexible search is used, which makes it possible to include in the search process the possibility of identifying components that do not strictly correspond to all specified search restrictions, but are the most suitable from those available in the database, for example, they correspond to 4 out of 5 parameters.
If the search is completed successfully, then a number of actions can be performed on the found component: print it, send it, open it for editing (the old version of the OBS component is saved, a separate copy is created), create a document in the electronic document management tool.
As an example of retrieving information from a database, let's take the creation of a query in the SQL language - finding out all the components working with the queue under index 4. Figure 4 is shown below, showing both the structure of the query and the result of the query. As a result of executing the requests, we see that the queue of interest to us is used by the 19 and 20 components as the output data queue, and the module 25 as the input data queue.
The developed method makes certain requirements for the process of entering information into the database, which are dictated by the need for clear structuring and building links between metadata for flexible search. Figure 5 depicts these relationships as relational database relationship diagrams.
Using the previously developed design method for the components of the cross-platform OBS of communication and navigation satellites, which involves the stage of architectural and detailed design, we define the attributes of the components as metadata elements that allow identification, and the set of metadata for each component is complete and sufficient to unambiguously identify an individual component and create a flexible system search by partial match. We will also include in the metadata the information about the component being developed that is necessary in the development process to specify the binding of components to specific equipment (names of supported ports, types of ports, names of queues). The developed descriptive information model of the knowledge area related to the elements of the components of the cross-platform OBS of communication and navigation satellites will be stored in a relational database.
The above procedure for development, formalized recording and functional identification, implemented by means of manipulating an electronic relational database, allows you to effectively organize the creation, storage and retrieval of software components. In general, the process of working with a separate component can be divided into stages for which you can create rules for filling in the database: creation of a new component (all numbers of administrative documents become elements of metadata associated with the components). Rule - it is necessary to fill in a complete list of metadata related to administrative document flow, physical parameters of the selected development platform and specific parameters, data when forming a task for creating components; search for a component similar to the one under development. Rule - if the search for strict compliance did not give any results, launch a flexible search for partial compliance, carried out by means of the main and foreign keys of the base; editing / creating the required component, observing the decomposition rules for elements sent to the database for storage (information about the developer also becomes a metadata element).
Rule - one component can have several developers, it is necessary to save intermediate versions; component testing, test results also become metadata elements belonging to a specific component. Rule - it is necessary to fill in all fields in a structured manner that are responsible for certain characteristics of the testing process; sending the document to the archive (the electronic version of the archive document is tied to the component). Rule - after sending to the archive, it is impossible to change the metadata or to carry out a cascade deletion by the component number; component search (performed by searching for a set of metadata associated with a specific component or by its id, if known). Rule - when searching, use standard templates written in the development environment; further work with the found component (after sending the component to the archive, there is only one editing option - creating a new instance, which can be linked to the original block through metadata). Rule - when creating a child block based on an old instance, the new component is assigned its own index and metadata space.
The result of going through all the stages and the execution of the rules will be a built structure of a relational database that has the ability to fully describe all the necessary metadata and has the correct links between them. Figure 6, Figure 7, Figure 8 show an example of the description of the modules entity, created using the presented pre-identification method.
Figure 8 shows the types of data stored in attributes, as well as the parameters for the uniqueness of these attributes.
Figure 8 shows all the foreign keys working in the modules entity and their corresponding tables.
Thus, the developed identification methods provide the ability to identify previously developed components in order to reuse them. They also allow verification of components in the process of project development for the correspondence of the attributes of the components to the architecture of the project.
The research is carried out with the support of the Krasnoyarsk Regional Fund for Support of Scientific and Scientific and Technical Activities, within the framework of the project "Control of the flight trajectory of aircraft in the extreme conditions of the Arctic and the Far North" in accordance with application 2021110907918. The authors are grateful to the China Aviation Industry General Aircraft Zhejiang Institute Co., Ltd for supporting this study and creating favorable conditions for research. 7. References