Zhibin Yang
email: yangzhibin168@163.com

Yang Bao

Yongqiang Yang

Zhiqiu Huang

Jean-Paul Bodeveix

Mamoun Filali

Zonghua Gu

Exploiting augmented intelligence in

Keywords: Safety-critical autonomous system, Augmented intelligence, Restricted natural language requirements, Natural language processing, Machine learning, SysML

Introduction

Safety-critical systems (SCS) are systems whose failure could result in loss of life, significant property damage, or damage to the environment. There are many well-known examples in different domains such as aircraft flight control, space missions, and nuclear systems. The SCS has the characteristics of high reliability, high safety, and strong real-time.

In the last decade, Artificial Intelligence (AI) is used increasingly in safety-critical systems, especially the aerospace engineering [START_REF] Dannemann | Techniques of artificial intelligence for space applications -a survey[END_REF] [START_REF] Tipaldi | A survey on model-based mission planning and execution for autonomous spacecraft[END_REF]. While a minimum level of autonomy is required for every aerospace system, past experiences have shown that it requires more complex autonomy to make the system to do decisions by itself in uncertain environments. For instance, deep space missions always need autonomous operations to deal with long communication delays and resource-constrained environments. There have been a number of examples of autonomous operations, such as vision-based sensing, attitude control [START_REF] Martens | A survey on artificial intelligence trends in spacecraft guidance dynamics and control[END_REF], communication with Earth, docking, soft-landing, anomaly detection [START_REF] Dannemann | Techniques of artificial intelligence for space applications -a survey[END_REF], fault detection isolation and recovery (FDIR) [START_REF] Dannemann | Techniques of artificial intelligence for space applications -a survey[END_REF], etc., which can be implemented as machine learning components (called as ML components). Using ML to learn system features is fundamentally different from manually implementing them in conventional components written in source code. Compared to human-readable source code, ML components are intrinsically hard to interpret. Thus, there has been a growing concern on the risks of using ML. Trustworthiness is becoming increasingly relevant as humans are progressively sidelined from the decision/control loop of intelligent and learning-enabled machines [START_REF] Sifakis | Autonomous systems -an architectural characterization[END_REF][START_REF]A human-centric approach to AI in aviation[END_REF]. There are several categories for classifying and discussing AI/ML trustworthiness, such as modeling [START_REF] Sifakis | Autonomous systems -an architectural characterization[END_REF], specification, formal verification of AI systems [KHI + 19, LAL + 19, AAHR16], testing [START_REF] Fitash | Comparing offline and online testing of deep neural networks: An autonomous car case study[END_REF], runtime monitoring, process assurance, and certification [START_REF]A human-centric approach to AI in aviation[END_REF], and so on. For instance, [LAL + 19] surveys the methods that have emerged recently for formal verifying whether a particular deep neural network satisfies certain input-output properties. More recently, European Union Aviation Safety Agency (EASA) gave an AI Roadmap [START_REF]A human-centric approach to AI in aviation[END_REF] to discuss the implication of AI on aviation systems. They also proposed four aspects such as learning assurance, AI explainability, AI safety risk mitigation, and trustworthiness analysis, to have an importance in gaining confidence in the trustworthiness of an AI/ML application. [FGH + 20] shows how the probabilistic model checker PRISM is used for optimal strategy synthesis for a sequence of scenarios relevant to UAVs (Unmanned Aerial Vehicle) and potentially other autonomous agent systems. Ryan Kirwan et al [START_REF] Kirwan | Model checking learning agent systems using promela with embedded C code and abstraction[END_REF] proposed model checking learning agent systems using Promela with embedded C code and abstraction, to help ensure the safety of autonomous systems.

In this paper, we make a first step towards exploring the architecture modeling of safety-critical autonomous systems which are composed of conventional components and ML components, based on natural language requirements.

Research Problems

Model-Driven Development (MDD) is generally accepted as a key enabler for the design of safety-critical systems. For example, in the guidance of civil avionics software certification (DO-178C) [START_REF] Thomas | RTCA DO-178C/EUROCAE ED-12C. Digital Avionics Handbook[END_REF], MDD (DO-331), and formal methods (DO-333) were considered as vital technology supplements. There are several MDD languages and approaches covering various modeling demands, such as UML for generic modeling, SysML1 for system-level modeling, AADL [START_REF] Peter | Model-based engineering with AADL: An introduction to the SAE architecture analysis & design language[END_REF] for the architectural modeling and analysis of embedded systems, SCADE 2 and Simulink for functional modeling, and Modelica for multi-disciplines modeling. However, the increasing amount of ML in safety-critical autonomous systems demands MDD engineers to adapt their work [START_REF] Vogelsang | Requirements engineering for machine learning: Perspectives from data scientists[END_REF]. One of the difficult activities is the architecture modeling of such systems, based on natural-language requirements.

Systems Modeling Language (SysML) was designed by the International Council on Systems Engineering (INCOSE) and the Object Management Group (OMG). As a profile of the UML 2.0, it was created specifically for the systems engineering domain, in order to integrate multiple views of large complex systems engineering consisting of hardware, software, requirements, data, people, and processes. Moreover, SysML provides several extension mechanisms such as stereotypes, diagram extensions, and model libraries. Thus, SysML is considered as the architecture modeling language in this paper.

However, when aligning to the principle of automation of MDD, automatically deriving architecture models directly from requirements in the context of developing safety-critical autonomous systems is a very challenge. One reason is that requirements are mostly written as free natural language text, which is often ambiguous, and difficult to be processed automatically and generate meaningful downstream design artifacts (e.g., models) from such requirements [START_REF] Yue | Facilitating the transition from use case models to analysis models: Approach and experiments[END_REF].

Restricted natural language requirement templates serve as a simple and yet effective approach for increasing the quality of requirements by avoiding complex structures, ambiguity, and inconsistency in requirements [START_REF] Arora | Automated checking of conformance to requirements templates using natural language processing[END_REF]. For instance, Tao Yue et al. proposed Restricted Use Case Modeling (RUCM) [START_REF] Yue | atoucan: An automated framework to derive UML analysis models from use case models[END_REF][YBL13] to reduce ambiguity and facilitate the automated analysis of use case models. EARS (Easy Approach to Requirement Syntax) [START_REF] Mavin | Easy approach to requirements syntax (ears)[END_REF] specifies requirements with several sentence templates to improve the quality of requirements. Spacecraft Requirement Description Language (SPARDL) [WLZ + 10] describes requirements with mode diagrams and interval temporal logic, for modeling and analyzing periodic control systems. In our previous work, we proposed a restricted natural language requirement specification method for AADL [WYH + 20].

To promote the application of MDD in safety-critical autonomous systems and bridge the gap between textual requirements and SysML models, we propose a requirements specification methodology, named as RNLReq, which is equipped with a set of restriction rules and templates to structure and restrict the way how users document requirements. To the best of our knowledge, it is the first contribution towards a restricted natural language requirement modeling for SysML. Compared with the existing restricted natural language requirement specification approaches such as [YBL15, MWHN09, WLZ + 10, WYH + 20], this work mainly focuses on the following two research questions:

• Are there any ML-specific requirements that need to be considered when ML is deployed in a safetycritical system? There is not much work on Requirements Engineering (RE) for ML-based safety-critical autonomous systems. [START_REF] Horkoff | Non-functional requirements for machine learning: Challenges and new directions[END_REF] states challenges and research directions for non-functional requirements of ML systems such as fairness, transparency, privacy, security, and testability. Andreas Vogelsang et al. [START_REF] Vogelsang | Requirements engineering for machine learning: Perspectives from data scientists[END_REF] conclude that the development of ML systems demands requirements engineers to: (1) understand ML performance measures to state good functional requirements, (2) be aware of new quality requirements such as explainability, freedom from discrimination, or specific legal requirements, and (3) integrate ML specifics in the RE process. However, the existing work hasn't considered ML-specific requirements when ML is deployed in a safety-critical context. For instance, the characterization of ML models must encompass more than just accuracy, i.e., it should consider the resource constraints in terms of memory, power, compute, and so on. Moreover, the system in a safety-critical application always consists of both conventional components and ML components. • How to use AI technologies to assist the restricted natural language requirement modeling? In the existing restricted natural language requirement specification approaches such as [YBL15, MWHN09, WLZ + 10, WYH + 20], it always needs to extract requirements glossary terms and to classify the requirements by hand. Recently, the OMG AI-SECT (Augmented Intelligence for Systems Engineering challenge team)3 introduced AI to model-driven system engineering in order to improve system model accuracy, content exploration, team productivity, and so on. They claimed that AI is already beginning to impact various system engineering aspects, such as system modeling, verification, process management, etc., and AI becomes a means to augment rather than replace human capability, that is "Augmented Intelligence (AuI)" [START_REF] Azad | Exploiting augmented intelligence in systems engineering and engineered systems[END_REF]. AI can collaborate with human systems engineers to measurably improve the system engineering effort. Thus, we would like to explore AuI in restricted natural-language requirement specification for safety-critical autonomous systems, which includes glossary terms recommendation and requirements classifications.

In addition, we propose RNLReq2SysML to automatically derive SysML architecture models from requirements specified with RNLReq. Besides, we implemented a tool for both RNLReq and RNLReq2SysML in Papyrus4 . An industrial Autonomous Guidance, Navigation and Control (AGNC) as a case study for the proposed approach has been carried out and it provides some positive feedback and lessons.

Main Contributions

The main contributions of this paper are presented as follows:

• Augmented Intelligence for restricted natural language requirement modeling of safety-critical autonomous systems. Firstly, in order to assist the RNL requirement modeling method, the IR4RNL (Intelligent Recommendation for RNL) method is proposed, including term recommendation and requirement classification. Especially, the term recommendation method recommends data dictionary and domain glossary, which are parts of RNLReq. The requirement classification method predicts the category of requirements. Secondly, the RNLReq method is proposed, which is equipped with a set of restriction rules and templates to structure and restrict the way how users document requirements.

Outline

The rest of this paper is organized as follows. Section 2 briefly introduces the concept of augmented intelligence in system engineering and the SysML language. Section 3 gives the requirement analysis of the target system of this paper, i.e., safety-critical autonomous systems. A global view of the approach is presented in Section 4. Section 5 gives the details of augmented intelligence for natural language requirement modeling. Section 6 presents the automatic generation of SysML architecture models. The prototype tool is presented in Section 7. Section 8 gives a real-world aerospace industrial case study to show the effectiveness of the proposed approach in this paper, and the threat to the validity of our approach is also presented. Section 9 discusses related work, and Section 10 provides concluding remarks and plans for future work.

Preliminaries

This section first briefly introduces the concept of AuI in model-driven system engineering. Then, the SysML language is described.

Augmented Intelligence in Model-Driven System Engineering

As claimed by Azad M. Madini [START_REF] Azad | Exploiting augmented intelligence in systems engineering and engineered systems[END_REF], the underlying technologies powering AI and AuI are the same, but the goals, usage, and application context are fundamentally different. AI creates systems operating without the need for humans, whereas AuI uses AI to augment human performance, which for many activities will be superior to the individual human or AI performance. It is also important to realize AuI is not a new technology category; rather, it is a different way to think about AI technology's purpose. While researchers pursue AI to see how far it can go is an admirable goal to realize key technologies proving invaluable in the future, the real world today is better served by AuI.

From the point of view of system engineering, AI is already beginning to impact various system engineering aspects. These include systems modeling, verification, process management, search and information retrieval, dynamic content management, and human-system integration. As shown in Figure 1, AuI systems engineering encompasses the system, the infrastructure support facilities, and processes. However, compared with [START_REF] Azad | Exploiting augmented intelligence in systems engineering and engineered systems[END_REF], we have added safety analysis and requirement specification as the system engineering activities which are vital for safety-critical autonomous systems. In each case, the AI is AuI. This paper will focus on the AuI in natural language requirement modeling and the SysML architecture models generation from such requirement specifications. The AI technologies which are used in our AuI consist of natural language processing, text similarity calculation, clustering algorithm, and classification algorithm for machine learning. Especially, in our empirical evaluation (Section 8), firstly, nine syntactic measures including Block distance[GF + 13], Cosine[GF + 13], Dice's coefficient[GF + 13], Levenshtein [START_REF] Manning | Introduction to information retrieval[END_REF], Euclidean[GF + 13], Jaccard[CRF + 03], Jaro[CRF + 03], Jaro-Winkler [CRF + 03] and SimHash-Hamming [START_REF] Sood | Probabilistic near-duplicate detection using simhash[END_REF] are considered. Secondly, for semantic similarity, we consider two strategies based on Hownet [START_REF] Liu | Word similarity computing based on hownet[END_REF] and CiLin [START_REF] Jiule | Method for calculating similarity of words based on cilin[END_REF], which can support the Chinese language. Thirdly, for clustering, we considered K-means, EM, and hierarchical clustering. Finally, classical machine learning algorithms including logistic regression, naive bayes, support vector machine, K-nearest neighbors, and random forest are considered in the requirement classification.

SysML

As UML is insufficient in capturing all the concepts that are meaningful in systems engineering, Systems Modeling Language (SysML) was designed by the International Council on Systems Engineering (INCOSE) and the Object Management Group (OMG). In addition to reusing a subset of UML 2.0, SysML provides new features towards system engineering including the ability to represent requirements and constraints of systems and to support trade-off analysis. A SysML model is made up of several diagrams that can be specified into three categories. Block definition diagrams(BDD) and internal block diagrams(IBD) capture the architecture of the system, with parametric diagrams describe constraints on property values to support future analysis. Requirement diagrams capture requirement, and requirement relationships. Activity diagrams, state machine diagrams and use case diagrams describe the behavior of the system. By extending a metaclass or generalizing an existing stereotype, SysML allows users to extend and adjust existing metamodels for different domains.

Requirement Analysis of Target Systems

Autonomous systems, such as deep space missions, autopilots, mobile robots, and autonomous vehicles belong to the spectrum of safety-critical applications. In this paper, we mainly focus on the safety-critical autonomous systems in the space domain. Observability and controllability of space systems are naturally limited due to several factors, such as communication delays, power budgets, and so on. Introducing more complex autonomy can increase the efficiency of many on-board missions of the space systems. On-board autonomy management addresses all aspects of on-board autonomous functions that provide the space system with the capability to continue mission operations and to survive critical situations without relying on ground system intervention. The implementation of on-board autonomy depends on the specific mission requirements and constraints, and can therefore vary between a very low level of autonomy involving a high level of control from the ground to a high level of autonomy, whereby most of the functions are performed on-board. For instance, the European Cooperation for Space Standardization (ECSS) [START_REF]Space Segment Operability (ECSS-E-ST-70-11C)[END_REF] defines four levels of such autonomous capabilities.

AGNC

The Guidance, Navigation, and Control (GNC) system is a core system supporting orbiting operations of spacecraft, which undertakes the tasks of determining and controlling spacecraft attitude and orbit. GNC is composed of navigation sensors (such as navigation cameras, star sensors, gyroscopes, and accelerometers), actuators (such as reaction flywheels, nozzles, orbit-controlled engines), and control computers (such as attitude and orbit control systems, AOCS) which process the guidance and control tasks of various sensors, perform orbit determination, orbit control, attitude determination, and attitude control. In addition, a data process unit (DPU) is added between navigation sensors and AOCS to preprocess the data sent by navigation sensors. Generally, AOCS has more than 20 modes such as stable, maneuver, safe, autonomous, and so on. The so-called mode is an operational state of a spacecraft, subsystem, or payload in which certain functions can be performed.

Figure 2 shows a simplified GNC structure with stable and autonomous modes, which is named AGNC (Autonomous Guidance, Navigation, and Control). In the stable mode, AOCS provides the missions by using conventional components. In the autonomous mode, to achieve autonomy, it uses an architecture including five complementary stages, i.e., perception, reflection, goal management, planning, and self-adaptation. Note that, the first two stages deal with "understanding" the situation of the environment. The third and forth aspects deal with the autonomy of decision. Self-adaptation ensures the adequacy of decisions with respect to the environmental situation. For instance, one can use ML to implement perception and autonomous decisions. Based on a data or knowledge base, a model is trained off-line on the ground and then can be queried by an on-board mission. Although insufficient training data exists for many applications, significant data from Earth, the Moon, and Mars is already available for machine learning applications. Moreover, data for off-line training can be obtained either by simulation or experiment or the past experiences.

Machine learning, particularly deep learning, is being increasingly utilized in different space applications [START_REF] Kothari | The final frontier: Deep learning in space[END_REF]. Here, we present three scenarios that can be implemented as ML components.

• Imagery transmissions. The images captured by the spacecraft need to be transmitted to the ground station for aggregation and analysis. However, sending and receiving large volumes of imagery is power consuming. In addition, the high-latency and low-bandwidth communication channels make this prohibitive. Thus, a spacecraft can reduce the amount of imagery transmitted by employing neural networks: on-board pre-processing can discard parts of the image of no interest. For instance, the images used as inputs to the neural networks can be 224 × 224 or 256 × 256 RGB images. Transmission costs can be further reduced by employing a neural network to compress image data. • Rendezvous and docking. Autonomous rendezvous and docking are defined as one spacecraft approaching another one autonomously, from close proximity, with hard constraints on the final position, the final speed, and the final attitude of the spacecraft. For instance, the active spacecraft (usually referred to as chaser ) observes the passive spacecraft (target) from almost 1km away and gather the spacecraft trajectory data. The AGNC system of the chaser controls the state parameters required for entry into the docking interfaces of the target vehicle. A simplified deep neural network structure is shown in Figure 3. The input layer receives the state information including the position of the chaser, the attitude and angular velocity of the chaser, the speed of the chaser, the position of the target, the attitude and angular velocity of the target, and the speed of the target. The hidden layers can be more than 20 layers. And the output layer controls the thrusters with two possible actions: left and right. • Fault detection, isolation, and recovery (FDIR). The spacecraft may suffer from faults physically and/or by interfering with communications. In such situations, it is imperative that the spacecraft should have an autonomous ability to detect faults and other anomalies. Stottler et al [START_REF] Stottler | On-board, autonomous, hybrid spacecraft subsystem fault and anomaly detection, diagnosis, and recovery[END_REF] proposed an ML-based fault detection approach, in which a two-layer artificial neural network (ANN) is introduced. Once trained on normal system behavior, the ANN model is used at detecting behavior previously not encountered in the training data (i.e., anomalies). Upon detecting anomalous behavior, it uses a supervised classification approach to determine a subset of measurands that characterize the anomaly.

Requirement Categories of AGNC

In a recent survey, [START_REF] Horkoff | Non-functional requirements for machine learning: Challenges and new directions[END_REF] and [START_REF] Ishikawa | How do engineers perceive difficulties in engineering of machine-learning systems?: questionnaire survey[END_REF] reported that requirement specification was listed as the most difficult activity for the development of ML-based systems. Andreas Vogelsang et al [START_REF] Vogelsang | Requirements engineering for machine learning: Perspectives from data scientists[END_REF] provided the first contribution towards a requirement engineering methodology for ML systems, that is, they concluded that developing ML systems demands requirements engineers to: (1) understand ML performance measures to state good functional requirements, (2) be aware of new quality requirements such as explainability, freedom from discrimination, or specific legal requirements, and (3) integrate ML specifics in the requirement engineering process. However, they haven't considered ML-specific requirements when ML is deployed in a safety-critical context. Based on the previous cooperation and the communication with our industrial partners, we conclude the requirement categories of the AGNC system shown in Table 1. Here, we mainly explain the requirements of ML components which are given as follows.

Conventional components

Functional requirements A description of the service that the system must offer.

Interface requirements

Various interface relations between system and environment.

Data requirements

Describe the various data used by the system and the requirements for data collection. Non-functional requirements Including safety, reliability, real-time, performance, environmental constraints, etc.

ML components

Goal requirements

The goal given by the stakeholder.

AI Functional requirements

Describe the learning process of machine learning, such as problem type, algorithm (or model) description, etc. AI Non-functional requirements Including safety/reliability, real-time, performance (such as the quality of the resulting prediction, such as accuracy, precision, recall, etc.), resource consumption, environmental constraints, explainability, robustness, etc. Training/testing/operational data requirements Including the quantity and quality of the training/testing/operational data, such as consistency, completeness, correctness, diversity.

• From the point of view of stakeholders: it is hard to specify the detailed functional behaviors of an ML component with explicit code. However, the decision of ML components should be based on the stakeholder needs, that is the goal requirements. In addition, requirement engineers always give a basic specification of the process of machine learning, such as the problem type, the used ML algorithms, etc. We call it a functional requirement of the ML component. The ML components also need to satisfy some non-functional attributes such as safety, reliability, real-time, explainability, robustness, and so on, in that, ML components always interact with an uncertain environment, so sometimes it needs several environmental constraints, for instance, temperature, wind speed, and so on. In addition, the safetycritical autonomous system is always resource-constrained, thus the characterization of ML models must encompass more than just accuracy, i.e., it should consider the resource constraints in terms of memory, power, compute, and so on. • From the point of view of ML implementation: Firstly, data is an integral part of ML components, thus the requirements of training/testing/operational data quality play an important role for specifying components than for conventional components. Secondly, based on a data or knowledge base, a model is trained that can then be queried by an application. Therefore, the resulting prediction, such as prediction precision, accuracy, and recall, that is, performance requirements, need to be well understood by system engineers.

Please note that this paper explores the architecture modeling of safety-critical autonomous systems based on natural language requirements, instead of directly specifying and verifying the characteristics of AI components such as their safety and robustness.

Global View of the Approach

A global description of the approach proposed in this paper is shown in Figure 4. It mainly contains two parts:

• AuI for restricted natural language requirement modeling. Firstly, we propose the IR4RNL (Intelligent Recommendation for RNL) method to assist the RNL requirement modeling. Especially, the term recommendation method recommends a glossary and the requirement classification method predicts the category of requirements. Finally, the glossary and the category of requirements will be used in the restricted natural language requirement template RNLReq, to specify the natural language requirements in a controlled format. • Automatic generation of SysML architecture models from the RNLReq requirement specifications. Firstly, in order to support the description of the specific requirement types of safety-critical autonomous systems In the following sections, we will present the two parts respectively. Please note that we mainly consider Chinese natural language requirement text in the IR4RNL (Intelligent Recommendation for RNL) method. However, in the restricted natural language requirement template RNLReq, each term in glossary and data dictionary contains both a Chinese name and an English name, thus the SysML model in English can be generated and the user interface can be adapted to Chinese.

Augmented Intelligence for Natural Language Requirement Modeling

This section gives the details of augmented intelligence for natural language requirement modeling. First of all, Section 5.1 presents the IR4RNL (Intelligent Recommendation for RNL) approach, which including term recommendation method and requirement classification method. Second, Section 5.2 presents the RNLReq method. Finally, Section 5.3 introduces the meta-model of RNLReq.

IR4RNL: Intelligent Recommendation for RNL

This section presents the intelligent recommendation for restricted natural language (IR4RNL), as shown in Figure 5. IR4RNL mainly consists of two parts: term recommendation and requirement classification. The data dictionary and the domain glossary, which are parts of RNLReq, can be recommended by the terminology recommendation method. The requirement classification method can assist in the establishment of the requirement template, which is also a part of RNLReq.

Terminology Recommendation Method

Given a natural language requirement, it first recommends candidate terms by interacting with engineers, then computes a similarity matrix for the candidate terms, and finally clusters the candidate terms based on their similarity.

Phase 1: Candidate term extraction. Candidate term extraction method includes text pre-processing, candidate terms extraction based on part-of-speech rule, candidate terms extraction based on dependency rule and domain filtering. Part-of-speech rule and dependency rule are used to extract candidate terms based on POS (part-of-speech) tagger and dependency parsing respectively, resulted from text pre-processing.

• T ext pre processing. The process of text pre-processing contains sentence splitter, word segmentation, POS tagger, and dependency parsing. Sentence splitter divides the natural language requirements into sentences. Word segmentation determines the word boundaries in a sentence. Then, the POS tagger annotates each word with a part-of-speech tag. The final step is dependency parsing, where an attempt is to recognize a sentence and assign a syntactic structure. In this paper, text pre-processing is achieved through the existing natural language processing tool HanLP [START_REF] He | Hanlp: Han language processing[END_REF] (Han Language Processing). Figure 6 and Figure 7 show the text pre-processing results of one of requirements of AGNC in normal modes and in the autonomous mode respectively. In that, ATT, ADV, COO, SBV, RAD, POB, LAD and VOB represent attribute relationship, adverbial relationship, coordinate relationship, subject-verb relationship, right additional relationship, preposition-object relationship, left additional relationship and verb-object relationship respectively. For instance, "autonomous", "management" and "module" are tagged as "vn", "vn" and "n" respectively. The relation between "autonomous" and "module", and the relation between "management" and "module", are ATT (attribute relation).

• Candidate terms extraction based on part-of -speech rule. Chinese domain terms have special linguistic characteristics: 1) From the perspective of external associations, domain terms are mostly noun phrases (NPs), which are often used as subjects, objects, and attributions in domain texts; 2) From the perspective of their internal grammatical composition, their composition forms including nouns + nouns (for instance "security agency"), adjectives + nouns ("combustible materials"), verbs + nouns ("launching devices"), verbs (nouns) + single-word nouns ("airtight doors"), etc; 3) The length of Chinese domain term is always two to six words. In this step, we introduce engineer feedback loop which is described in our AuI approach. Firstly, it formulates part-of-speech pattern matching rules based on the preliminary glossary extracted by the engineers. Please note the preliminary glossary should comply with the Chinese linguistic characteristics shown above. Secondly, candidate terms are extracted according to the part-of-speech pattern matching Fig. 7. The text pre-processing results of a requirement of AGNC in the autonomous mode rules. Thirdly, the engineers filter the candidate terms (addition, deletion, and modification), and then update the part-of-speech pattern matching rules. Finally, it repeats the second and the third steps until the engineers are satisfied. Regarding the requirement sentence given in Figure 7, for instance, engineers give part-of-speech pattern matching rules such as "vn+vn+n" and "vn+n" based on the preliminary glossary, thus there are three candidate terms that meet the part-of-speech pattern matching rules, such as "autonomous management module", "autonomous task " and "autonomous mode".

• Candidate terms extraction based on dependency rule. It includes three sub-steps: generating dependency tree, pruning, and generating candidate terms. Firstly, the requirement sentence is analyzed for dependency parsing to obtain the dependency tree. Secondly, Chinese domain terms are generally NPs, so we mainly consider four types of dependency relations such as the attribute relation (ATT), the coordinate relation (COO), the right additional relation (RAD), and the left additional relation (LAD).

With the four types of dependency relations, the dependency tree will be pruned as a set of dependency sub-trees. The definition of the dependency sub-tree is given as Definition 1. Finally, according to the generated dependency sub-trees, we select |V | > 1 and continuous strings as candidate terms. For example, "system module" and "autonomous module" are discontinuous strings, and the remaining dependency sub-trees are all continuous strings, so four candidate terms are generated, "autonomous management module", "management module", "autonomous task " and "autonomous mode".

Definition 1. Given a dependency tree T = (V, A), its dependency sub-tree T = (V , A ) satisfies the following constraints:

(i) V ⊆ V , A ⊆ A.
(ii) There is a single designated root node that has no incoming arcs. (iii) With the exception of the root node, each vertex has exactly one incoming arc. (iv) There is a unique path from the root node to each vertex in V. (v) The root node is a noun or verb.

The candidate terms extraction algorithm based on dependency rules is shown in Algorithm 1. Firstly, each requirement is analyzed for dependency parsing and a dependency tree is generated; Secondly, generate dependency sub-trees that contains only four types of dependency relationships: ATT, COO, LAD, and RAD; Finally, each string in each dependency sub-tree is analyzed, to extract continuous strings with length greater than 1 as candidate terms. end for 12: end for

• Domain f iltering. The domain characteristics of a term mean that the term usually appears only in one or a few domain-specific texts. It is determined by comparing the number of occurrences of term candidates in our domain requirements with the occurrences in a non-domain-specific text corpus. For example, we eliminate all candidate terms that occur less frequently in our requirement corpus than in a subset of the THUCNews 5 corpus. It ensures that all candidate terms have a minimum degree of domain specificity. In addition, stop words refer to some very common words, and removing them will not affect the semantics of the requirement. Thus we further filter candidate terms with stop words and finally extract four candidate terms, including "autonomous management module", "management module", "autonomous task " and "autonomous mode".

Phase 2: Computing similarities between terms. In this step, it computes a similarity matrix to capture the degree of relatedness between every pair of candidate terms extracted in the previous step. To compute this matrix, we consider three alternative strategies[ASBZ16]:

(i) syntactic only, where a similarity, S syn (t, t ), is computed for every pair (t, t ) of terms using a syntactic measure, e.g., Levenshtein; (ii) semantic only, where a similarity, S sem (t, t ), is computed for every pair (t, t ) of terms using a semantic measure, e.g., Hownet; (iii) combined syntactic and semantic, where, given a syntactic measure syn and a semantic measure sem, we take, for every pair (t, t ) of terms, max (S syn (t, t ) , S sem (t, t )). Using max is motivated by the complementary nature of syntactic and semantic similarity measures.

Phase 3: Clustering candidate terms. We cluster the candidate terms based on their degree of relatedness. The inputs of this step are the similarity matrix, the choice of the clustering algorithm to use, and the number of clusters, and K. As the result of clustering, the candidate terms are grouped into K partitions [START_REF] Arora | Automated extraction and clustering of requirements glossary terms[END_REF]. For example, "GNC " and "AOCS " are treated as the candidate terms in the same cluster.

In the case study shown in Section 8, we use K-means, Expectation-Maximization (EM) and, Hierarchical Clustering algorithms to cluster candidate terms to investigate the key questions related to tuning clustering for use in our application context. Specifically, identifying the most accurate clustering algorithm(s) is addressed in RQ5, see Section 8.2.2.

Requirement Classification Method

The requirement classification method is composed of five phases:

Phase 1: Data-sets collection. Firstly, according to the national standard Software Requirements Analysis: requirement analysis documents are divided into eight types: functional, performance, interface, data, environment, safety, modifiability, and assumptions and constraints. Secondly, according to the Aerospace Product Reliability Assurance Requirement, the reliability metrics of aerospace products are required. We select five typical requirement categories to collect data-sets, which are functional, performance, safety, reliability, and interface. The scale of the data-sets is shown in Section 8.2.2.

Phase 2: Text pre-processing. We preprocess requirement by segment, POS tagging, and stop words elimination.

Phase 3: Features extraction. Two feature extraction techniques BoW and TF-IDF are used to extract textual features and calculate the wright of features. We use these textual features and the weight of features to train classifiers.

Phase 4: Classifier. Five machine learning algorithms, including Naive Bayes, Logistic Regression, Support Vector Machine, K-Nearest Neighbors, and Random Forest, are used to train classifiers. The requirements are automatically classified by the trained classifiers.

Phase 5: Evaluation. We use precision, recall, and F-score to evaluate the performance of the classifiers which are trained in Phase 4. The calculation formula is shown in Section 8.2.2.

RNLReq: Restricted Natural Language Requirement Template

This section presents the Restricted Natural Language Requirement Specification Method (RNLReq), which can reduce ambiguities of natural language requirements without changing the requirements writing habits 5 http://thuctc.thunlp.org/ of system engineers. A typical requirement document from industries consists of such as sections of functionalities, tables of domain terms, and tables of data. Each functionality is organized as IPOC (Input-Process-Output-Constraint) structure. Thus, RNLReq consists of three parts: Data Dictionary, Domain Glossary and RNL templates with well-defined sentence patterns based on restriction rules.

Data Dictionary & Domain Glossary

In the domain of safety-critical systems, requirements engineers are always recommended to construct a data dictionary and a domain glossary first. A well-organized domain glossary and structured data dictionary can enhance the requirement engineering processes in a number of ways. For instance, they can help improve the understanding of requirements and reduce the vagueness and ambiguity of requirements, which can promote better communications among stakeholders and provide a stepping stone for further requirement elaboration.

Therefore, data dictionary and domain glossary are included in RNLReq, and they are organized as follow:

• Data dictionary, refers to a dictionary covering the data and its attributes scattered in the requirements documents. All the data should be specified with name, id, data structures (can be comprised of simple data types, e.g. integer, character, etc., and complex structure, e.g. arrays, struct, union), unit, range, rate, quality, quantity, and description. Table 2 shows the Backus-Naur Form grammar (BNF) of the data dictionary. In order to present the continuous and discrete dynamic characteristics in SCS systems, Rate is specified with a numerical value or a distribution. In order to express specific requirements of ML components, we need to consider data quality and data quantity. Data quantity includes the size and diversity of data. Data quality includes completeness, consistency, and correctness. Five restriction rules D1-D5 constraining data quality are presented in Table 3. In order to ensure completeness, Rule D1 checks the sparsity of data within each characteristic. Rules D2, D3 are used to ensure the consistency of data. Rule D4 emphasizes on data collection process which has a strong influence on the correctness of data. Rule D5 reduces the discrimination and bias in data resulting from humans.

According to the actual needs of the industry, the data dictionary can include static data, input data, output data and so on. Among them, static data refers to the constants in the system; input data refers to the input of each component; and output data refers to the output of each component.

• Domain glossary, refers to a dictionary covering the domain terms scattered in the requirements documents, such as the names of systems, functions, interfaces, properties, modes, hardware, states, etc. All terms documented should be specified with name, id, category, and description. Table 4 shows the BNF grammar of the domain glossary.

Here, we give several examples to show how to build data dictionary and domain glossary from requirement sentences.

Example 1: Given a functional requirement "The Perception Function sends the data collected by the sensor to the Decision Function every 10ms, and the data collected by the sensor includes angular velocity and angular position.", we first register the data in the data dictionary: [name: Sensor angular data, ID: d001, struct: (angular velocity, angular position), unit: NA, range: NA, rate: 10ms, quality: NA, quantity:(size: 1), description: NA]. Here, NA means Not Applicable. It should be noted that the angular velocity and angular position need to be registered in the same way. Then, we register two terms in the domain glossary: With the help of terminology recommendation methods in Section 5.1, we can get the recommendations of data dictionary and domain glossary.

Requirement Templates

It is a common practice in industry to decompose requirements hierarchically, and each decomposed requirement is organized as a typical IPOC structure. Therefore, we defined a set of requirement specification templates in RNLReq, which can be organized hierarchically.

Requirement specification templates are organized as four levels according to the decomposition of requirements in industry: System Requirement Template (SRT) presents the highest level requirement of the system, and engineers can decompose it as several sub-system requirements which can be described in Sub System Requirement Template (SubSRT). The decomposition of SubSRT can be iterative. Then, each SubSRT can be decomposed as several Function Requirement Template (FRT), and FRT can also be decomposed as Sub Function Requirement Template (SubFRT). The standard for the granularity of templates, especially whether SubSRT should be decomposed as FRT instead of lower-level SubSRT, is the strategy of implementations for each sub-system and function.

Besides, it is possible that some functions or sub-functions from different systems present the same or similar functionality. To simplify the requirement specification for such a situation, we defined a Share Function Block Template (SFBT), which only belongs to systems or sub-systems, and can be invoked from any template in these systems or sub-systems.

Table 5 shows the basic requirement template which can support the requirements of both conventional components and ML components. To be consistent with the requirement types presented in Table 1, in general, the template includes ID, Name, Input/Output (including Data and Event), F unctional Requirement, Non-F unctional Requirement (including Safety/Reliability Requirement, Performance Requirement, Environmental Requirement, etc.), AI Requirements (optional), and Description. When we use the requirement template to specify the requirements of ML components, the F unctional Requirement and Non-F unctional Requirement are noted as NA, and AI Requirements include the requirement types which has been shown in Table 1, such as goal requirements, training data quality requirements, and so on. Each category of the requirements, such as F unctional Requirement, Non-F unctional requirements and so on, should follow their specific templates.

R1

The subject of a sentence must be the name of modules or "this module". R2

The sentence must be a declarative sentence.

R3

The sentence must be in the present tense.

R4

Do not use passive voice.

R5

Only complete sentences are allowed. R6 Don't use modal verbs, pronouns, adverbs and adjectives that express negative meanings.

R7

Same words should be used to represent the same object.

R8

Describe interactions between systems without dismissing subjects or objects.

General Restriction Rules

For each category of requirements shown in Table 5, a set of general restriction rules (R1-R8) in Table 6 are designed to constrain the use of natural language. R1 is to ensure the feasibility of hierarchy modeling and behavior modeling. R2-R5 are good practices for writing requirements and reduce the ambiguity. R6 can help reduce the uncertainty in requirements. R7 ensures the same concept will be expressed in a consistent way. R8 facilitates the automated generation of models. We further refine the rules for specific requirements such as functional requirements, non-functional requirements and AI requirements and illustrate with examples.

Functional requirement Restriction Rules

Functional requirements (FR) focus on what the system does and emphasizes the inputs, outputs, sequences, and conditions for coordinating behaviors. For functional requirements, each sentence pattern represents a complex sentence structure, which is composed of sequences of simple sentences connected with a set of keywords (e.g., IF T HEN ELSE, AN D, LOOP F OR, NOT ). Five simple sentence patterns are designed for functional requirements as shown in Table 7. For a better understanding, we also give an example for each sentence pattern in the table.

SimpleBehaviorSentence is used to express basic functional behavior, while SimpleBehaviorSentence Therefore, with the combination of multi-level compound structures, RNL templates can represent complex behaviors. The structure of functional requirements is shown in Figure 8: From the structure of the template, we can see that the whole functional requirement template is a composite behavior. The behavior slot in the figure can be filled with a list of simple behaviors or nested composite behaviors, making the functional requirement template robust and scalable to express complex functional behavior.

Non-functional requirement Restriction Rules

Non-functional requirements (NFR) focus on how good the system does and the constraints it faces. Note that NFRs do not exist independently, they are a supplement to functional requirements.

NFR encompasses the following attributes: performance, safety, reliability, environmental constraints and so on. Among them, the NFR attributes that can be quantitatively described and analyzed includes performance, reliability, and safety. The time performance of the system, namely real-time requirements, include periodic/aperiodic execution, deadline, time-out, jitter, response time, schedulability, etc. Resource performance of the system includes resource consumption (e.g. power consumption, CPU, storage, bus) and constraints of the physical environment (e.g. temperature, quality, and pressure). Reliability requirements include such as the probability of system failure.

For an on-board ML component which lives in resource-constrained environment, in order to obtain the optimal solution, an NFR constraint on the property may vary over time and be influenced by objective cost, performance and failure rate. Thus, the property value is constrained by the trade-off of several objectives.

As shown in Table 9, we present the restricted sentences applicable to NFRs. On the one hand, we can give quantitative NFRs with ConstraintSentence, RangeSentence (a variation on ConstraintSentence). On the other hand, we can collaborate qualitative NFRs with corresponding System/Functional Templates, such as ConditionnalSentence for fault handling and P eriodicitySentence for periodicity, allowing system engineers to take functional and non-functional aspects into consideration at the design stage. Besides, the Trade-Off sentence describes the fact that the property has a relationship "optimizedBy" with the mentioned objectives and can be calculated by a method/function.

AI requirement Restriction Rules

Compared with conventional components, ML components automatically obtain a machine learning model by executing a training algorithm with training data-sets, and then evaluate trained models using testing data-sets. However, ML techniques are not applicable for behavioral modeling and should be treated as "black boxes". A lack of requirements specification in ML components has a great impact on the whole system. Thus, as shown in • Quantity. It is obvious that "We expect a better performance of the model if we have more data and more diverse data", thus, properties of data quantity like size, diversity are included in the data specifications.

Due to the fact that training data and testing data originate from the same source, they should share the same data specifications. • Completeness. Completeness specifies the sparsity of data within each characteristic.

• Consistency. Consistency is guaranteed by the consistency between input data and test data (assuming the same environment). • Correctness. Correctness is strongly influenced by the way how the data is cleaned, collected and stored.

Operational Data. Just like for conventional components, ML components take data as input at operation time, namely input data, or operational data. Though training data and testing data are approximately equally distributed, their relationship to the input data which tends to change with time or environment is unclear. Thus, it is important to check for consistency between input data and training, testing data, that is why we need to specify the distributions.

Goal. Goals are defined as well defined criteria for satisfaction such as evaluation metrics, an expected state of a system, an expected range of predictions. When a model makes bad predictions (outlier), it is natural to ask humans for information which may be unsuitable for time-critical tasks, so returning fallback values is a potential option in that case.

AI Functional Requirement. ML encompasses over a dozen problem types (e.g., Binary or Multiclass Classification, Regression, Clustering), with many more specific algorithm types (e.g., Logistic Regression, Linear Regression, Naive Bayes, Nearest Neighbor, Deep Neural Networks). In order to get a global view of ML solutions used, our specifications include problem types, algorithm types, layer information in Deep Learning systems and characteristics of models when updating.

AI Non-functional Requirement. To ensure the robustness of ML components, several dimensions of non-functional quality such as safety/reliability, real-time, performance and explainability are considered. Meanwhile, in respect that this article focuses on safety-critical systems, fairness which prevents the phenomenon that ML bias stems from prejudicial training data are ruled out.

• Safety/Reliability. If the safety/reliability estimation of individual predictions reach the threshold, changes such as retraining model or refining solutions should be made. • Real-time & Performance. The accuracy (how correct the output is) and real-time (how fast the process is) properties of ML components need to be guaranteed, and fallback plans need to be specified. • Resource consumption. The on-board computation and communication are resource-constrained, such as bandwidth for sending/receiving data, power consumption, memory and storage for data buffer. • Explainability. Although ML models are opaque constructs that are intrinsically hard to interpret, engineers are able to give specifications to explain the behavior of the model around a given data point or features.

For example, a requirement in AGNC system, "The Decision Subsystem needs to detect small celestial body in large images provided by the navigation camera, while a model with precision of 80% is needed.", introduces a goal requirement "The Decision Subsystem need to detect small celestial body in large images" and a performance requirement "Model satisfy a ConstraintSentence with precision >80% " to specify an AI requirement of the Decision Subsystem.

The Meta-Model of RNLReq

The process of requirement specifications in RNLReq essentially contains three parts: data dictionary & domain glossary, requirement templates and sentence patterns. Thus, we define the meta-model of RNLReq as shown in Figure 9: • Data Dictionary & Domain Glossary, used for specifying data and terminologies in requirements. Each data refers to an instance of DataW ord and each terminology refers to an instance of T erm in the meta-model. • T emplates, are organized as requirement templates for systems, sub-systems, functions, sub-functions and shared function blocks. Each template inherits from a super class AbstractT emplate, and higher-level templates can take lower-level ones as their composition. • Sentence P atterns, each type of requirements in templates is organized as a list of sentences, which

Real-time

The time spent should be in an acceptable range[min,max]. Specify the fallback plans.

Resource consumption

The resource spent should be in an acceptable range[min, max].

Explainability

Specify the features that can derive the desired output or decisions. Specify the features that have a negative effect on the result. Give explanations on the behavior of the model around a given data point.

Description Extra description of this module. (No restriction rule here)

satisfy predefined sentence patterns. Each sentence pattern inherits from a super class Sentence, and their transformation rules are defined in the gen() operation of Sentence. F unctionalSentence is composed of ConditionalSentence and CompoundBehaviorSentence. N onf unctionalSentence is composed of ConstraintSentence and its variations. Most of the new AI requirement types reuse existing sentences, and Goal requirements are fulfilled with GoalSentence.

Automatic Generation of SysML Architecture Models

As safety-critical autonomous systems feature a tight combination of the system's computational, physical and communication parts which are heterogeneous, we propose a multi-view approach based on SysML for Fig. 9. The Meta-Model of RNLReq modeling of these systems, which allows designers from different views to focus on particular aspects of the system. Firstly, we present the subset of SysML: SubSysML; then, the transformation from RNLReq to SysML architecture models is given.

Subset of SysML

The meta-model of SubSysML is summarized in Figure 10. SubSysML consists of a block definition diagram (BDD), internal block diagrams (IBD), activity diagrams (ActD) and stereotypes such as ConstraintRequirement and MLComponent. This paper considers several complementary views of safety-critical autonomous systems: hierarchy view, inter-communication view, functional view, non-functional view, and data view. Each view highlights certain features of the system and are illustrated as follows.

• Hierarchy view. Due to the fact that most systems are built compositionally and made of sub-systems or components which are connected in some way, hierarchy view reflects the compositionality of the systems. Hierarchy view is represented by a BDD and its elements such as blocks and MLcomponents (nodes in yellow color). Blocks are the key elements of BDDs and can represent basic structural decompositions for modeling static structures of systems. Properties of blocks represent the states and attributes of systems. MLComponent is a sub-stereotype of SysML block stereotype and has properties describing characteristics of data and algorithms in AI Requirement Template. Given a system, SubSysML specifies the system model as a BDD. Inside the BDD, it uses blocks or MLcomponents to express the hierarchical structure of the system. • Inter-communication view. Inter-communication view reflects the interactions of different sub-components in the systems. Inter-communication view is represented by IBDs and its elements such as Port and • Functional view. Functional view reflects the dynamic behavior of a system. Functional view is represented by an activity diagram and its elements (nodes in blue color). SubSysML contains several kinds of Activity Nodes such as call behavior actions (represent a basic unit of functionality within the activity), initial/final node (mark the start/end of an activity), fork/join nodes (mark the start/end of concurrent sequences), decision/merge node (mark the start/end of alternative sequences), send signal actions (send a signal instance to a target), accept event actions (wait for a signal to continue the activity). Activi-tyPartition allocates activity nodes to blocks. ConstraintRequirement for an activity node can represent some constraints such as timing that should be satisfied by a running component.

• Non-functional view. In non-functional view, we extend the existing SysML Constraint stereotype to specify the non-functional properties, including safety, reliability, performance and so on. Figure 11 is the definition of the ConstraintRequirement of the system. ConstraintRequirement can contain an OCL expression that formally states an acceptance condition, threshold for a traditional component, or a data requirement for an ML component. For example, Figure 12 shows the use of ConstraintRequirement to describe the property of the working temperatures of a sensor.

• Data view. Data view captures the data structure of the system using objects, attributes, operations, and relationships. We extend SysML's V alueT ype stereotype to model the data structure of the system which is specified by Data Dictionary. The BaseT ype package contains the predefined primitive value types such as Integer 16, Float 64 and Boolean. The DataT ype package contains all data types defined by system engineers.

Transformation from RNLReq to SubSysML

As shown in Figure 13, the transformation from RNLReq to SubSysML is composed of five parts. The first part is intended for identifying incorrect templates and preprocessing the RNLReq. For example, if a SystemTemplate has an input port while the corresponding output port cannot be discovered, the RNLReq is incorrect and needs to be repaired. Part 2-5 transform information in checked RNLReq to separate diagrams with mapping rules. The process is achieved by the following algorithms.

As described in the Algorithm 2, it takes RNLReq meta-model (given in Section 5.3) as input. In Line 1-3, each data defined in the Data Dictionary will be transformed into the value types in SubSysML. In Line 4-6, a block definition diagram is generated for the SystemTemplate at the top level. In Line 7-11, each SubSystemTemplate considered as siblings of the SystemTemplate will be transformed into a block and attached to the BDD, and the properties of blocks are generated. The hierarchy of SystemTemplates is generated into a tree: SystemTemplate at the top level is the root block, and its sub-templates are modeled as blocks in the next level. In Line 10, each block connects with the top system block via connectors using a composition relationship.

The process of generating inter-communication view is defined by Algorithm 3. We first check whether each SubSystemTemplate (son) contains interface requirements. If it contains I/O information, then an IBD is generated and associated with the corresponding block of the SystemTemplate (parent) at the higher level. Generate a composition connector named topST +subT and multiplicities of subT ; 11: end for Then, the block corresponding to each SubSystemTemplate will be added into the IBD, and ports will be used to express the communication between them. for each connection c in S do 13: Generate ports with its corresponding data types and attach them to subT property; 14:

Algorithm 3 Generate inter-communication view

Generate connectors between ports;

15: end for 16: end for All the functional requirements are translated into activity diagrams, which is shown in the Algorithm 4. The structure of Functional Requirement Template in Figure 8 is considered as a tree. Each SimpleSentence and ConditionSentence is considered as a leaf node (which is solvable and has a corresponding SysML element). Line 9-12 and Line 21-27 show the rule mapping ConditionSentence and SimpleSentence into corresponding Activity Nodes. Line 13-14 shows that ComplexSentence is a non-leaf node and contains several leaf nodes inside. We search the tree recursively, until all the sub-trees are searched and solved, which means the entire function requirements have been transformed into an activity diagram. Besides, as using swimlanes to notate ActivityPartitions is usually complex and impractical, Line 22-23 allocates nodes to partitions by placing the partition name in parenthesis above the ActivityNode name into the ActivityNode symbol.

In addition, Algorithm 7 shows the process that non-functional/AI requirements is inserted into the diagrams generated in the steps above. In Line 4-7, ConstraintSentence and RangeSentence described in Section 5.2.5 are transformed into OCL expression and then added into ConstraintRequirement. In Line 8-12, behavior constraints such as deadline and WCET are added into activity diagrams as a constraint of

Prototype Tool

We have implemented our approach in a prototype tool named SCASAMTool (Safety-Critical Autonomous Systems Architecture Modeling Tool). It mainly includes the intelligent recommendation tool IR4RNL, the requirement specification tool based on restricted natural language RNLReq, and the SysML model automatic generation tool RNLReq2SysML. Figure 14 shows the overall architecture of SCASAMTool. It is developed on the Eclipse platform integrated with Papyrus plug-in. The open-source modeling tool Papyrus6 provides complete modeling support for SysML. A brief description of each module is given below.

• IR4RNL. IR4RNL includes term recommendation and requirement classification methods. Especially, terminology recommendation method takes natural language requirements as input, and recommends candidate data dictionary and candidate domain glossary through interaction with requirement engineers. The requirement classification method predicts the category of requirements by the trained model. • RNLReq. RNLReq further formulates the data dictionary, domain glossary, and category of requirements from IR4RNL, and specifies the RNL structured requirements with the requirement templates.

• RNLReq2SysML. RNLReq2SysML takes RNLReq requirement specification as input, and generates SysML models through transformation rules.

The SCASAMTool adopts a modular architecture, in which it includes 6 modules such as Terminology Recommendation, ReqTemplate Viewer, ReqTemplate Controller, RNLReq2SysML Mapper, SysML Element Generator and SysML Layout Visualizer. Table 11 shows the main function code statistics of the SCASAMTool.

Evaluation

Industrial Case Studies

The requirement document of AGNC is obtained from the industrial partner. The document extends to more than 200 pages, written in Chinese and contains nine sections (such as Attitude Determination, Orbit calculation, Attitude Control, Orbit Control, etc.). For the sake of confidentiality, just a small portion of the requirement is allowed to present in this paper.

First, we recommend data dictionary, domain glossary, and requirement category based on the original requirement document with the prototype tool. Then, we specify the RNLReq modeling for AGNC system in Figure 15. The left side is the hierarchical structure of the requirements. The right side is the requirement template editor, the engineer can add and edit different categories of requirements through the restriction rules of the requirement template. After the entire RNL template has been completed, a SysML model of the AGNC system can be generated automatically.

Next, the generated SysML system architecture model is presented in Figure 16, in which the yellow blocks represent device stereotype and the blue ones represent the ML components in the autonomous mode. The architecture of AGNC system is a hierarchical control structure: 1) According to the working process of the system, the whole system is divided into several parts: data sampling sub-system, control function sub-system, action sub-system, etc. 2) For instance, control function sub-system can be further divided into attitude control sub-system, attitude check sub-system, orbit calculate sub-system, orbit control sub-system and output pre-processing sub-system. 3) Attitude control sub-system is further divided into Local Terminal Unit, perception sub-system, decision sub-system, self-adaption sub-system, and action sub-system. 4) The devices include sensor components (such as navigation cameras, star sensors, gyroscopes, and accelerometers) which collects signals from environment and data process unit which process the data and command.

Then, Figure 17 shows the system inter-communication model of the Attitude Control sub-system, which has a stable mode (filled with orange color) and an autonomous mode (filled with blue color). On the left side, interactions of the autonomous mode are illustrated, local terminal unit first collects data (such as navigation images and physical parameters) and sends them to the perception sub-system. Then the perception sub-system integrates the environment information and sends them to the decision sub-system. Decision sub-system delivers plans to the action sub-system which controls the actual executive agents, and Fig. 15. Structure of RNLReq requirements of AGNC system the feedback of executive agents will help improve the ability of self-adaption sub-system. On the right side, interactions of the stable mode are simpler: control components receive data from local terminal unit and send commands to executive agents directly. Compared to the process of autonomous mode, process of stable mode lacks the ability of self-adaption and a central decision module.

Besides, Figure 18 shows the activity diagram of a sub-system for eliminating the initial deviation in AGNC system. Eliminate Initial Deviation(EID) of Attitude Control sub-system eliminates the angular rate of attitude generated by the separation of satellites from launch vehicles by calling some three-axis attitude control algorithms of spacecraft. First, it sends the angular velocity of X, Y, Z axis gyros to the control sub-system. Depending on the values, it calculates the state of orbit. Then, it sends signals to executive agents and keeps a backup of data. If getting into orbit, it will send a signal for the success of first catch of the earth.

Finally, Figure 19 shows a safety requirement about losing control of the control function sub-system, "Control function sub-system may occur a current short-circuit fault, a memory fault, and an over-temperature fault. The probability of a current over-temperature fault is 1.0E-7". According to the Failure entry defined in the data dictionary, the corresponding user-defined stereotype Failure is generated. Failure level, failure type, failure probability, etc., in its internal structure are converted into the attributes such as FailureEffect, Severity, Likelihood, and ProbabilityValue in the Failure stereotype. For the block ControlFunction-init having the safety requirement, Failure stereotype is used as the type of the attributes CurrentFault, Mem-oryFault, and CurrentThermal in the block, and values of these attributes are acquired from the safety sentences in RNL templates, for example, the ProbabilityValue of CurrentThermal is 1.0E-7.

Statistics data of the case study is given in Table 12. It shows that the case study, 1) covers all the RNL templates mentioned in Section 5.2; 2) has a considerable number of RNL elements; 3) shows the correspondences between RNL elements and SysML model elements.

Analysis Results

Analysis of RNLReq2SysML

• Research Questions

The major objective of this subsection is to evaluate the effectiveness of our approach. This objective is decomposed into the following research questions:

RQ1. Can we use our approach to cover the requirements from the aerospace domain?

As a model generation approach, the RNL templates proposed in this paper should be able to cover various kinds of requirements. In order to answer the question, we have applied our approach to requirements from different aerospace sub-systems.

Table 13 provides the name, the short description, the domain and the number and coverage of the requirements from three industry cases. For the description of Case-A, see section 3.1. For Case-B, the rocket control system refers to a system that uses sensors, on-board computers, and communication equipment to control the launch of a rocket, and provide stability for the rocket. Case-C is the aircraft air pressurization system (AAPS), which is one of sub-systems to ensure the normal operation of the aircraft. Its core component is the air pressurization controller, which is used to drive the motor to operate, thereby driving the air compressor to work. The coverage of RNL templates is nearly 91 percent and we believe the samples are enough for evaluation. Requirement statements that cannot be covered include one or more complex mathematical expressions. The predefined sentence patterns show good ability in expressing requirements, and if one wants to apply RNL to other domains, the predefined sentence patterns are designed with high flexibility and expansibility.

RQ2. Are our transformation rules from RNLReq to generated SysML models complete?

We use the following procedure to check the completeness of our approach: 1) Take the same requirements specifications (AGNC system) as input; 2) Generate the SysML models with RNLReq2SysML tool; 3) Check whether each template have been transformed into SysML elements; 4) Check whether Data Dictionary has been transformed as data types; 5) Check whether each SysML diagram is well-organized and shows up in the Papyrus environment.

Y Y Y Y Y Y Composition N Y N Y Y Y Attributes Y Y Y Y Y Y Methods N N N Y Y Y Multiplicity Y N N N Y Y InterCommunication N N N N N Y Activity N N N Y N Y NFR N N N N N Y
Following the above procedure and engineers' feedback from industry, for all RNLreq requirements of the case study AGNC, we achieved 100% completeness of transformation with RNLReq2SysML. Statistics of RNL elements and SysML elements keeps consistent with each other as presented in Table 12, note that the number of entries in Data Dictionary and the predefined 8 primitive types constitutes the number of DataType. Besides, the generated SysML diagrams conforms to the SysML 1.6 standard.

RQ3. How many SysML modeling concepts can our approach cover when compared with other approaches?

We compare the proposed RNLReq2SysML tool with the international tools: CM-Builder [START_REF] Harmain | Cm-builder: A natural language-based case tool for object-oriented analysis[END_REF], DC-Builder [START_REF] Ben | From user requirements to uml class diagram[END_REF], UMLG [START_REF] Samad | Object oriented software modeling using nlp based knowledge extraction[END_REF], aToucan [START_REF] Yue | Facilitating the transition from use case models to analysis models: Approach and experiments[END_REF], ABCD [START_REF] Singh | Automatic builder of class diagram (abcd): an application of uml generation from functional requirements[END_REF]. Please note that, in the RNLReq2SysMLtool, Chinese natural language requirement text is mainly considered, and subsequently remarked that each term in glossary and data dictionary contains both Chinese and English names, therefore English SysML models can be generated. By conducting a survey on the modeling ability of these tools, we evaluate their coverage of the modeling concepts such as of SysML/UML. As shown in Table 14, compared to other tools, 1) with the help of SysML BDDs, RNLReq2SysML tool can capture more structure information such as multiplicity, compositions from NL requirements; 2) with the help of SysML IBDs, RNLReq2SysML can generate diagrams describing intercommunication and activity; 3) RNLReq2SysML supports the description of NFRs. By using RNL and SysML together, SysML's advantages in graphical modeling are enforced with RNL's efficiency in capturing requirements.

Analysis of IR4RNL

• Research Questions IR4RNL method evaluation aims to answer the following research questions (RQs):

RQ4. How effective is the candidate term extraction method combined with engineer feedback loop? In the term recommendation method, we add engineer feedback loop to the candidate term extraction. The aim of RQ4 is to evaluate whether the engineer feedback loop can give better term recommendation.

RQ5. Which similarity measure(s) and clustering algorithms(s) yield the most accurate cluster? The choice of similarity measures and clustering algorithms can have a major impact on the quality of the generated clusters. The aim of RQ5 is to examine alternative combinations of similarity measures and clustering algorithms, and identify the best alternatives in terms of accuracy.

RQ6. Which feature extraction method(s) and classifiers(s) yield the most accurate results in requirement classification method? The choice of feature extraction methods and classification algorithms can have a major impact on the quality of the requirement classification method. The aim of RQ6 is to examine alternative combinations of feature extraction methods and classifiers, and identify the best alternatives in classification accuracy.

• Evaluation Procedure

Our case study is based on three evaluation procedures: the first is to evaluate the accuracy of candidate terms extraction, the second is to evaluate the accuracy of term clustering, and the third is to evaluate the accuracy of requirement classification.

RQ4. Accuracy of Candidate Terms. We use standard classification accuracy metrics, precision and recall, to evaluate the accuracy of candidate terms. The task at hand is to determine which candidate terms belong to the glossary and which ones do not. The candidate terms that belong to the glossary are True Positives (TP), and the ones that do not belong are False Positives (FP). The glossary terms that are not extracted by our tool are False Negatives (FN). Precision accounts for the quality of results, i.e., smaller number of FPs, and is computed as T P/(T P + F P ). Recall accounts for the coverage, i.e., smaller number of FNs, and is computed as T P/(T P + F N) . We use F-measure to combine precision and recall into one metric. F-measure is computed as: 2 × P recision × Recall/(P recision + Recall).

RQ5. Accuracy of Clustering. In this paper, meaningful handling of overlaps is essential: while our clustering approach (Section 5.1.1) produces partitions, i.e., non-overlapping clusters, our ideal clusters are overlapping. To evaluate the accuracy of clustering, we use a simple set of accuracy metrics i.e., a standard generalization of precision, recall and F-measure for clusters which is straightforward to interpret in the presence of overlaps. The algorithm of calculating these accuracy metrics for clustering is shown in Algorithm 6 [START_REF] Arora | Automated extraction and clustering of requirements glossary terms[END_REF].

RQ6. Accuracy of Requirement Classification. For the multi-class classification problem, this paper uses macro metrics to meausure the performance of classification results. Precision, Recall, and F1 are defined as:

P macro = 1 |G| |G i=1 T P i T P i + F P i = |G| i=1 P i |G| R macro = 1 |G| |G| i=1 T P i T P i + F N i = |G| i=1 R i |G| F 1 macro = 1 |G| |G| i=1 2 × P i × R i P i + R i = |G| i=1 F 1 i |G| Algorithm 6
Precision(I i , G j ) = nij |Gj | . 4: Recall (I i , G j ) = nij |Ii| . 5: F -measure (I i , G j ) = 2×Precision(Ii,Gj )×Recall(Ii,Gj )
Precision(Ii,Gj )+Recall(Ii,Gj ) . 6: For every ideal cluster I i 1 ≤ i ≤ t: 7: Let G r be the best match for I i among generated 8: clusters, i.e.,F -measure (I i , G r ) ≥ F -measure (I i , G j ) for any 1 ≤ j ≤ u. Let P best match (i) denote P recision (I i , G r ) and let R best match (i) denote Recall (I i , G r ). 9: Let n = t i=1 |I i |. 10: Compute overall precision and recall as weighted-averages of the precisions and recalls of the ideal clusters:

11: P recision = Σ t i=1 |Ii| n × P best -match (i). 12: Recall = Σ t i=1 |Ii| n × R best -match (i).
• Results and Discussion We take Case-A as the example, the experimental dataset is shown in Table 15. We manually identified 237 standard terms (golden standard) for 220 requirements. In order to get better recommendations, we set engineer feedback times to 10. Please note that we also count short terms that are included as parts of longer terms of the other set. The experimental results are shown in Figure 20. The experimental results show that as the number of engineer feedback increases, the accuracy, recall, and F-measure of the candidate term extraction method are all improving. Finally, the precision, recall and F-measure are 41.5%, 70.5%, 52.2% respectively, that is, candidate term extraction method extracts 455 candidate terms and 137 as standard terms.

The preliminary part-of-speech rules and the final part-of-speech rules are shown in Table 16. It can be seen that compared with the preliminary part-of-speech rules, the final part-of-speech rules are more abundant, which can better express the engineer's ideas.

For candidate term extraction, recall is a more important factor than precision. A low recall (i.e., a high number of false negatives) means that the engineers will miss many of the terms that should be included in the glossary. Low precision is comparatively easier to address, as it entails only the removal of undesired items (false positives) from a list of extracted candidate terms.

For low accuracy, we consider it is caused by the by-produces of part-of-speech rules and dependency rules. For example, as shown in Figure 7 above, when the candidate term "autonomous management module" was extracted, "management module" was also extracted, which is not the standard term. For the standard terms that have not been extracted, this paper believes that most of the reasons are caused by word segmentation errors. For example: "tube bomb", which is a part of the rocket control system, should be segmented as "tube bomb/n", but the wrong segmentation is "tube/n, bomb/v".

RQ5. Candidate term clustering method. As suggested by the discussion in RQ4, the number of candidate terms is more than the number of standard terms, that is, there are some non-standard terms. We note that outside an evaluation setting, one cannot distinguish terms that are relevant to the glossary from those that are not. To preserve the realistic behavior of clustering, it is thus paramount to compute the generated clusters for all the candidate terms first and then prune the results for evaluation.

To answer RQ5, we considered pairwise combinations of the nine syntactic similarity measures and two semantic similarity measures, which are introduced in Section 2.1. The total number of remaining combinations is (9 + 1) × (2 + 1) -1 = 29. These combinations include configurations where an individual syntactic or semantic measure is applied on its own. For clustering, we considered K-means, Hierarchical and EM. We evaluated each clustering algorithm in conjunction with all the 29 possible combinations of similarity measures, i.e., a total of 3 × 29 = 87 alternative cluster computations.

When the number of candidate terms is n and the selected number of clusters is K, increasing the value of K beyond n/2 will would have little practical meaning, as the average size of clusters would fall below 2 terms per cluster. Therefore, this paper restrict the upper range for K to a maximum of n/2 (upper bound). Specifically, firstly, for each alternative, this paper selects 10 points uniformly from 1 to n/2 as the value of K; Secondly, we compute the normalized F-Measure for each alternative.

In Table 17, it shows the top-10 alternatives that yield the best average accuracy, i.e., normalized Fmeasure. As shown in the table, the Jaro-Winkler similarity strategy in the best alternative does not produce stable results.

To provide a general recommendation, we need to further consider the effect of individual syntactic measures, semantic measures and clustering algorithms on accuracy across all the alternatives. More precisely, we would like to find similarity measures and clustering algorithms that yield good (but not necessarily the absolute-best) results, and at the same time, cause little variation. A standard way for performing such analysis is by building a regression tree [START_REF] Breiman | Classification and regression trees[END_REF]. Figure 21 shows the regression trees for the case study. The regression tree identifies at any level in the tree the most influential factor that explains the variation between the data points. In our context, there are three factors: (1) the syntactic measure, (2) the semantic measure, and (3) the clustering algorithm. Once the most influential factor is identified, the regression tree partitions the data points into two sets in a way as to minimize variations within the resulting sets.

In each node of the tree, it presents the count (number of alternatives), the mean and the mean-square error(MSE) for Normalized F-measure. By convention, sibling nodes in the tree are ordered from left to right based on their mean values. For every expanded (i.e., non-leaf) node, the node shows the difference between the mean values of its right and left children.

According to the regression tree results, we get the following observations: The first layer shows that for the mean of Normalized F-measure, the hierarchical clustering algorithm is 3.700 higher than the K-means algorithm and the EM algorithm, thus ruling out the K-means algorithm and the EM algorithm. For the second layer, the experimental results without the semantic similarity strategy are overall higher than using semantic similarity algorithm. The third layer shows that the experimental results of Jaro, Jaro-Winkler and SimHash-Hamming distance are higher than other grammatical similarity algorithms, thus we narrow the choices of syntactic measures to Jaro, Jaro-Winkler and SimHash-Hamming distance. To summarize our discussion of RQ5, we conclude that good choices of the similarity measures and the clustering algorithm, in Table 18. We note that despite semantic measures not being influential in improving clustering accuracy, we do not discourage the use of these measures. A potential reason why we did not find semantic measures useful is that semantic synonyms are not prevalent in our case studies. Semantic measures, when combined with syntactic ones, may be useful if the likelihood of (semantic) synonyms being present is high.

RQ6. Requirement classification method. We collect 250 requirements for each types of safetycritical autonomous software, including functional, performance, safety, reliability, and interface. a total of 1,250 requirement are collected. The data-sets covers national standard documents in most safety-critical areas, including software design requirements, aerospace software design requirements, and safety-critical software analysis and guidelines, etc.

Different feature extraction methods and classification algorithms are combined for comparative experiments. Specifically, we consider two feature extraction methods and five classification algorithms, a total of ten combination strategies. The experiment is based on the Scikit-learn machine learning library and fivefold cross-validation method. The experimental results of the combination method of the Bow-based feature extraction method and multiple classification models are shown in Table 19. The experimental results of the combination of the feature extraction method based on TF-IDF and the multiple classification models are shown in Table 20. The experimental results show that the combination of TF-IDF feature extraction method and SVM classification algorithm has achieved the highest evaluation result. Since experimental data-sets basically covers the requirements of safety-critical autonomous areas, and the division process of the data-sets adopts a random extraction method, the experimental results have a certain degree of versatility. The single experiments listed in Table 19 and Table 20 can also reflect the stability of different combination strategies. In summary, for the requirements of safety-critical autonomous software, the above combination strategies have achieved relatively good results.

Threats to Validity

We discuss threats to validity of our empirical results and the steps we have taken to mitigate these threats.

Internal validity. First, both the standard terms (golden standard) and standard term cluster (golden standard) are subjective processes. In order to reduce this threat, we request two researchers to mark the benchmark data and then review by domain experts to determine the benchmark data. Second, the review of domain experts may contribute to the experimental results of our method. In order to reduce this threat, domain experts are not informed of our method before and after the review process.

External validity. First, the data-sets in this paper covers most of the requirements of AGNC, and terminology recommendation method successfully generates a reasonable list of candidates terms. However, further case studies are necessary to improve external effectiveness. Second, the analysis results of our candidate term extraction method need to be improved. One feasible way is to use existing term extraction tools to process the cases in this paper, and systematically compare the results with our method.

Related Work

Section 9.1 presents several surveys on the AI-based safety-critical autonomous systems in the domains of such as space application and autonomous vehicles, and surveys on the challenges of developing of these systems, such as modeling, verification, and so on. This paper mainly focuses on the architecture modeling of safety-critical autonomous systems, based on natural language requirements, thus we present the related work on the requirement modeling of such systems in section 9.2. In section 9.3, it describes the existing work on AuI for natural language requirement modeling. [START_REF] Dannemann | Techniques of artificial intelligence for space applications -a survey[END_REF] shows a survey of the techniques of AI for space applications, in which it mainly focuses on the application of artificial intelligence in autonomous planning and scheduling of operations, self-awareness, anomaly detection and Fault Detection Isolation and Recovery (FDIR), on-board data analysis as well as on-board operations and processing of earth-observation data.

AI-based Safety-Critical Autonomous Systems and its Challenges

Dario Izzo et al. [START_REF] Martens | A survey on artificial intelligence trends in spacecraft guidance dynamics and control[END_REF] give a survey on AI trends in spacecraft guidance dynamics and control systems. They mainly focus on evolutionary optimisation, tree searches and machine learning, including deep learning and reinforcement learning, as the key technologies and drivers for current and future research in the field of spacecraft guidance and control.

Autonomous Vehicles (AV) are expected to bring considerable benefits to society, such as traffic optimization and accidents reduction. They rely heavily on advances in many AI approaches and techniques.

[NVM + 19] presents a systematic literature review about the impact of AI on autonomous vehicle safety.

Joseph Sifakis et al. [START_REF] Marron | Autonomics: In search of a foundation for next-generation autonomous systems[END_REF] propose that developing trustworthy autonomous systems requires addressing fundamental issues that have not been dealt with adequately by present research or industrial experience. Three main challenges are presented: 1) how to specify autonomous system behavior in the face of unpredictability, and behavioral specification is needed in virtually all stages and activities of the development process: requirements, design, simulation, testing, verification, and validation; 2) how to carry out faithful analysis of system behavior with respect to rich environments that include humans, physical artifacts, and other systems, it includes simulation, testing, formal verification, and system validation against the tacit needs of the stakeholders; and 3) how to build such systems by combining executable modeling techniques from software engineering with artificial intelligence and machine learning, for instance, combining "modelbased" and "data-driven" approaches.

There is a growing body of research on the verification and testing of AI-based safety-critical autonomous systems. For instance, [START_REF] Aniculaesei | Towards the verification of safety-critical autonomous systems in dynamic environments[END_REF] presents the formal verification of safety-critical autonomous systems in dynamic environments. The authors adopt a two phase process which combines static verification methods (with UPPAAL), used at design time, with dynamic ones, used at run time (using monitors). Lionel Briand et al. [START_REF] Fitash | Comparing offline and online testing of deep neural networks: An autonomous car case study[END_REF] compare offline and online testing of deep neural networks used in an autonomous car. Offline testing where DNNs are tested as individual units based on test data-sets obtained independently from the DNNs under test, and online testing where DNNs are embedded into a specific application and tested in a close-loop mode in interaction with the application environment.

Compared with the existing work, this paper mainly focuses on the architecture modeling of safety-critical autonomous systems with SysML, based on the natural language requirements.

Requirements Engineering for AI-based Systems

There is not much work on Requirements Engineering (RE) for AI-based systems.

[IY19] shows how practitioners currently perceive the difficulties and their causes in the engineering of ML-based systems. The authors report that RE was listed as the most difficult activity for the development of machine learning systems. [START_REF] Horkoff | Non-functional requirements for machine learning: Challenges and new directions[END_REF] states that much recent attention has been paid to certain qualities of machine learning solutions, particularly the non-functional requirements such as fairness, transparency, privacy, security, and testability.

Andreas Vogelsang et al. [START_REF] Vogelsang | Requirements engineering for machine learning: Perspectives from data scientists[END_REF] describe the characteristics and challenges unique to RE for ML-based systems. They conclude that development of ML systems demands requirements engineers to: (1) understand ML performance measures to state good functional requirements, (2) be aware of new quality requirements such as explainability, freedom from discrimination, or specific legal requirements, and (3) integrate ML specifics in the RE process.

[LFCL16] explores the steps that healthcare organizations may take to elicit data analytics requirements, to specify functional requirements for using data to improve business and clinical outcomes, to improve service quality while reducing costs.

However, the existing works have not considered ML-specific requirements when ML is deployed in a safety-critical context. Moreover, we envision that systems in safety-critical application are unlikely to be pure ML systems. Therefore, it needs to consider the requirements of both conventional components and ML components.

AuI for Natural Language Requirement Modeling

AI for Requirement Engineering

There are several work on how to use AI/ML to improve RE tasks such as requirement prioritization, categorization, domain models extraction, etc.

[PSA13] presents a machine learning approach to software requirements prioritization. Deciding which, among a set of requirements, are to be considered first and in which order is a strategic process in software development. This task is commonly referred to as requirements prioritization. The authors describe a requirements prioritization method called Case-Based Ranking (CBRank), which combines project's stakeholders preferences with requirements ordering approximations computed through machine learning techniques, bringing promising advantages.

[WV16] proposes an approach for automatic classification of requirements based on convolutional neural networks. Besides the actual requirements, these documents contain additional content such as explanations, summaries, and figures. It is important to be able to differentiate between legally relevant requirements and other auxiliary content. The authors present an approach to automatically classify content elements of a natural language requirements specification as "requirement" or "information (auxiliary content)". They also do evaluation on a real-world automotive requirements specification.

Lionel Briand et al [START_REF] Arora | An active learning approach for improving the accuracy of automated domain model extraction[END_REF] proposed an active learning approach for improving the accuracy of automated domain model extraction. The objective of this article is to develop automated assistance for filtering the superfluous information extracted by NLP during domain model extraction. The authors devise an active-learning-based approach that iteratively learns from analysts' feedback over the relevance and superfluousness of the extracted domain model elements and uses the feedback to provide recommendations for filtering superfluous elements.

Restricted Natural Language Requirement Modeling

Restricted natural language requirement templates serve as a simple and yet effective approach for increasing the quality of requirements by avoiding complex structures, ambiguity, and inconsistency in requirements [START_REF] Arora | Automated checking of conformance to requirements templates using natural language processing[END_REF].

Tao Yue et al. proposed Restricted Use Case Modeling (RUCM) [START_REF] Yue | atoucan: An automated framework to derive UML analysis models from use case models[END_REF][YBL13] to reduce ambiguity and facilitate the automated analysis of use case models. RUCM is composed of a set of well-defined restriction rules and a modified use case template. The goal is two-fold: (1) restrict the way users can document use case models in order to reduce ambiguity and (2) facilitate the manual derivation of initial analysis models which, when using the Unified Modeling Language (UML), are typically composed of class diagrams, sequence diagrams, and possibly other types of diagrams.

EARS (Easy Approach to Requirement Syntax) [START_REF] Mavin | Easy approach to requirements syntax (ears)[END_REF] specifies requirements with five sentence templates to improve the quality of requirements. A small set of structural rules was developed to address eight common requirement problems including ambiguity, complexity and vagueness. The ruleset allows all natural language requirements to be expressed in one of five simple templates. Moreover, the ruleset was applied whilst extracting aerospace engine control system requirements from an airworthiness regulation document.

[WLZ + 10] presents a formal modeling approach SPARDL(Spacecraft Requirement Description Language) as a concise and precise way to specify embedded systems, which can improve the quality of embedded systems in aerospace.

Compared with existing work, this paper provides a first contribution towards a restricted natural language requirement modeling for SysML, augmented with AI, that is AuI for restricted natural language requirement modeling approach.

Conclusion and Future Work

This paper made a first step towards exploring the architecture modeling of AI-based safety-critical autonomous systems, based on natural language requirements. Firstly, Augmented Intelligence for restricted natural language requirement modeling is proposed. In that, several AI technologies such as natural language processing and clustering are used to recommend candidate terms to the glossary. The glossary (including data dictionary and domain glossary) is used in the restricted natural language requirement template RNL-Req, which is equipped with a set of restriction rules and templates to structure and restrict the way how users document requirements. Secondly, in order to support the description of the specific requirement types of safety-critical autonomous systems, an extension of SysML is given, and then automatic generation SysML architecture models from requirements specified with RNLReq is presented. Thirdly, the prototype tools for both RNLReq and RNLReq2SysML are implemented based on Papyrus. Finally, an industrial Autonomous Guidance, Navigation and Control (AGNC) as case study for the proposed approach has been carried out and it provides some positive feedback and lessons.

In the future, we would like to consider more new AI technologies such DNN in our AuI method. In addition, as mentioned before, AI is already beginning to impact various system engineering aspects. These include safety analysis, requirement engineering, systems modeling, verification, process management, search and information retrieval, dynamic context management, and human-system integration. Therefore, we would like to explore AuI in other phases of system engineering, such as RNL template recommendation, safety analysis, formal verification, and so on. As safety-critical autonomous systems are often resource-constrained, we are currently working on the compositional verification on the SysML models to evaluate the trade-off between objectives such as performance, resource consumption, failure tolerance rate so as to determine the optimal solutions.

Fig. 1 .

 1 Fig. 1. AuI in system engineering [Mad20]

Fig. 2 .

 2 Fig. 2. AGNC Framework

Fig. 4 .

 4 Fig. 4. Global view

Fig. 5 .

 5 Fig. 5. IR4RNL method

Algorithm 1

 1 Terminology extraction algorithm based on dependency rules Input: Requirements Output: CandidateTerms 1: CandidateTerms = list() 2: for each Requirement in Requirements do 3: compute DepandencyTree of the Requirement; 4: compute DepandencySubtrees of only DepandencyTree of ATT, COO, LAD, RAD;

2 :

 2 [name: Perception Function, id: g001, category: function, description: NA], [name: Decision Function, id: g002, category: function, description: NA].Example In order to express safety and reliability requirements, we can register static data like FailureSeverity and FailureProbability in the data dictionary. For instance, given a safety requirement "The failure of rocket propulsion has four levels of severity: NoEffect, Minor, Major, Hazard", we register the static data: [name: FailureSeverity, ID: s001, struct: NA, unit: NA, range: (NoEffect, Minor, Major, Hazard), rate: NA, quality: NA, quantity: NA, description: NA]. To describe probability distributions of failure, we register the data FailureProbability: [name: FailureProbability, ID: s002, struct: NA, unit: NA, range: (Normal[mean, stdDev], Uniform, Basic[min,max]), rate: NA, quality: NA, quantity: NA, description: NA]. Example 3: For an ML component, given the data quality requirement "The size of the data-set is 100k, and 60% of the training data comes from Source A and the remaining is from Source B ", we register the data: [name: TrainingSet, ID: d003, struct: NA, unit: NA, range: NA, rate: NA, quality: NA, quantity:(size: 100k), diversity: (SourceA=60%, SourceB=40%)]. Table 2. BNF grammar of data dictionary <data-dictionary> ::= (<data>)+ <data> ::= <name> <ID> <struct> <unit> <range> <rate> <quality> <quantity> <description> <name> ::= (<letter> | <digit>)+ <rate> ::= <digit> | <distribution> <distribution> ::= <uniform> | <normal> <quality> ::= <completeness> <consistency> <correctness> <quantity> ::= <size> <diversity>

  <domain glossary> ::= (<noun>)+ <noun> ::= <name> <ID> <category> <name> ::= (<letter> | <digit>)+ <category> ::= 'system' | 'function' | 'interface' | 'property' | 'hardware' | 'mode' | 'states'

Fig. 8 .

 8 Fig. 8. Structure of Functional Requirement Template

Fig. 10 .

 10 Fig. 10. Meta Model of SysML Model

Fig. 11 .Fig. 13 .

 1113 Fig. 11. Definition of ConstraintRequirement Fig. 12. Threshold represented by ConstraintRequirement

Fig

  Fig. 14. SCASAMTool Achitecture

Fig. 17 .

 17 Fig. 17. Framework of Attitude Control Subsystem

Fig. 18 .

 18 Fig. 18. Function of eliminating initial deviation

Fig. 20 .

 20 Fig. 20. Evaluation results of candidate term extraction methods combined with engineer feedback

Fig. 21 .

 21 Fig. 21. Regression tree results

•

  Automatic generation of SysML architecture models from the RNLReq requirement specifications. Firstly, in order to support the description of the specific requirement types of safety-critical autonomous systems (data quality, quality of resulting prediction, safety, reliability, resource consumption, etc.), an extension of SysML is given. Secondly, based on the meta-model technology, we propose RNLReq2SysML to automatically derive SysML architecture models from requirements specified with RNLReq.• Prototype tool and industrial case study. The prototype tool for both RNLReq and RNLReq2SysML is implemented in Papyrus. In addition, the case study, i.e., Autonomous Guidance, Navigation and Control (AGNC), has been carried out.

Table 1 .

 1 Requirement Categories of AGNC

	Component	Requirement Types	Explanation
	Types

Table 3 .

 3 Rules of data quality

	No.	Description
	D1	Data must cover the whole range of possible values.
	D2	Additional data sources that satisfy hypotheses can be used to augment the original data to get a richer set of
		training data.
	D3	Each data in the data-set must be in the same format and representation.
	D4	Data must be validated and cleaned before use.
	D5	Don't collect or label data by humans.

Table 4 .

 4 BNF grammar of domain glossary

Table 5 .

 5 RNLReq Requirement Template

	Elements	Explanations
	ID	The unique identifier of this template
	Name	The name of the module described in this template
	Input	The input data and event of this module
	Output	The output data and event of this module
	Functional Requirement	The dynamic behavior of this module, such as sending data
	Non-functional Requirement	Performance such as period, deadline, Safety/Reliability such as failure mode, failure case,
		Environmental Requirement such as transmission rates of ports (Not in FRT, SubFRT
		& SFBT)
	AI Requirement	The description of ML components (Optional)
	Description	Extra description of this module. (No restriction rule here)

Table 6 .

 6 General Restriction Rules of Sentence Patterns

	No.	General Restriction Rules

Table 7 .

 7 Simple Behavior Sentences for Restricted NL

	No.	Sentence Pattern	Explanation		Examples
	S1	SimpleBehaviorSentence	A single sentence presenting	See examples of S2-S5.
			one action, including S2-S5.
	S2	Send	Send <Data> at <Port>	DPU sends processed data to AOCS at Port-1573B.
	S3	Assign	Assign <Data-A> to <Data-	Orbit control subsystem assigns orbitMode to LOW-
			B>		EARTH.
	S4	Call	Call	<System>	AOCS calls the orbit determination function.
			<SharedFunction>
	S5	Jump	Jump <Function>		AOCS jumps to orbit determination function each 15s
					when in Stable state.

Table 8 .

 8 Compound Behavior Sentences for Restricted NL Meanwhile (The Control Module sends data, the Control Module counts times).

	No.	Sentence Pattern	Description		Examples
	S6	SimpleValueCondition	IF <P1> <Comparator>	IF Attitude Deviation Angle is bigger than 26 degrees.
			<Value> <Unit>
	S7	ValueCondition	More than one SimpleVal-	IF conditionA AND conditionB.
			ueCondition connected with
			AND/OR
	S8	EventCondition	IF receiving <Event>	IF receiving Handshake Success Information, THEN
					AOCS sends GNCC Controlling Data to GNCC.
	S9	TimeCondition	DURING (T1, T2), IN D1	The Control Module sends Handshake Information to
					GNCC in 5ms.
	S10	ConditionnalSentence	IF Condition, THEN Sen-	IF receiving Handshake Success Information, THEN
			tenceA, [ELSE SentenceB]	the Control Module sends GNCC Controlling Data to
					GNCC, ELSE the Control Module sends Handshake
					Information to GNCC.
	S11	LoopSentence	LOOP SentenceA EACH T	LOOP (The Control Module sends data) UNTIL
			UNTIL E		POWER OFF.
	S12	ConcurrentSencence	MEANWHILE	(SentenceA,
			SentenceB, SentenceC, ..)

Table 9 .

 9 Non-functional Requirement Sentences for Restricted NL

	No.	Sentence Pattern	Explanation		Examples
	S13	ConstraintSentence	<property> <comparator> <value>	The period of SelfCheck function is 2ms. (Period-
			<unit> <margin of error>	icity)
					The maximum allowed failure probability of Star
					Sensor A is 5%. (Failure probability)
					The main freq of CPU is less than 90% of the max-
					imum. (Resource)
					The mass of the device is 4kg, with a 1% margin
					of error. (Resource)
					The severity of Losing Power in Control Subsystem
					is Level I. (Safety)
	S14	RangeSentence	<property> within [min,max]	The normal temperature range of CPU is within [45,70] • C.
	S15	PeriodicitySentence	LOOP SentenceA EACH T UNTIL E	In working state, the motor receives instructions
					every 10ms. (Periodicity)
	S16	TradeOffSentence	<property>	optimizedBy	The bandwidth of sending data optimizedBy the
			<obj1>,<obj2>,<obj3>	with	power, performance and failure rate with Func-
			<method>		tionA. (Cost reduction)

  Table 10, new requirement types are introduced and AI requirements are divided into six categories including training data, testing data, operational data, goal, AI functional requirements, AI non-functional requirements. Each category is described and further decomposed as follows. Training Data & Testing Data. ML approaches generate models based on a set of examples (training data) and evaluate models on another set of examples (testing data). Both data are collected at development time. This category is refined into quantity, completeness, consistency and correctness.

Table 10 .

 10 AI Requirement Template

	Elements	SubElements	Explanations
	ID		The unique identifier of AI template.
	Name		The name of the module described in this template.
	Training Data	Quantity	Specify sources of training data as a set like [A, B, C], and the corresponding
			diversity index as a set like [30%, 40%, 30%].
			Specify the size of data-set.
			Specify the feature set.
			Specify the distribution of running data.
		Completeness	Specify the coverage of the data on the whole range of possible values in percent.
		Consistency	Ensure that format and representation of data that should be the same in the
			data-sets.
		Correctness	Specify the data format standard that must be followed.
			Specify the database technology to use.
			Specify the augmenting rules for data.
			Specify the purging rules for data.
			Specify the mechanism to store meta-data.
	Testing Data		Same structure as Training Data.
	Operational Data		Specify the distribution of input data at operation time.
	Goal		System should be in an acceptable state set S.
			Specify the expected result range.
			Specify the fallback values in cases of an outlier predicted value.
	AI Functional		Specify the problem type, e.g. binary or multiclass classification, regression, clus-
			tering.
			Specify the algorithm name.
			Specify the frequency of model updating or creation.
			Specify the strategy to make predictions when the model is being updated.
			Specify whether the model supports making multiple predictions at the same
			time.
	AI Non-functional	Safety/Reliability Specify reliability estimation of individual predictions in machine learning.
		Performance	The evaluation metrics (like precision, recall) should be in an acceptable
			range[min,max].

Specify the algorithm type, e.g. Logistic Regression, Linear Regression, Naive Bayes. Specify the set of layers, including [layer name, input shape, kernel size, padding method, activation], e.g. Convolutional layer 1: The input dimension is (1, 32, 32); the size of the convolution kernel is (5, 5); the padding method is valid; the number of convolution kernels is 6; the activation function is tanh.

  Get top SystemTemplate topST in RNLReq; 5: Generate a SysML model Model with topST's name; 6: Generate an block definition diagram BDD with topST 's name; 7: Generate a block with topST 's name and its corresponding attributes; 8: for each SubSystemTemplate subT in topST with SYSTEM type do Generate a block Block with subT 's name and its corresponding attributes;

	Algorithm 2 Generate hierarchy/data view
	Input: RNLReq
	Output: BDD, BaseTypes
	1: for each Dataword DW in DataDictionary do
	2:	Generate a Datatype DT with DW 's name;
	3: end for
	4: 9:
	10:

  Extract ConditionSentence Con, IfSentence Action1, ElseSentence Action2 in Sen; If SS is ConcurrentSentence, generate ForkNode and JoinNode; Let name of SystemTemplate SS belongs to be partition name; Generate CallBehaviorAction if SS is Call, link it to the activity if SS points to another Func-tionTemplate; In Line 13-23, each SystemTemplate containing AIRequirement is transformed to blocks stereotyped with MLComponent in the BDD. The transformation of NFRs in AIRequirement (Line 17-21) is similar to the Line 4-7.

	Algorithm 4 Generate functional view
	Input: SystemTemplates containing Functional Requirements
	Output: ActDs
	1: for each SystemTemplate ST in RNLReq do
	2:	Generate an activity diagram ActD with ST 's name;
	3:	Get behavior sentence BS in ST ;
	4:	ProcessComplexSentence(BS);
	5:	function ProcessComplexSentence(Sentence BS)
	6:	Get sentence list SenList in BS;
	7:	for each sentence Sen in SenList do
	8:	if Sen is compound then
	9:
	10:	If SS is EventCondition, generate AcceptEventAction and Pin;
	11:	If SS is ValueCondition, generate DecisionNode and MergeNode;
	12:
	13:	ProcessComplexSentence(Action1);
	14:	ProcessComplexSentence(Action2);
	15:	Connect nodes generated in steps above;
	16:	else
	17:	ProcessSimpleSentence(BS);
	18:	end if
	19:	end for
	20:	end function
	21:	function ProcessSimpleSentence(SimpleSentence SS)
	22:
	23:	Append partition name to node name;
	24:
	25:	Generate CallBehaviorAction and Pin if SS is Assign;
	26:	Generate SendSignalAction and Pin if SS is Send;
	27:	end function
	28: end for
	corresponding ActivityNode.

Table 11 .

 11 Generate properties inAIblock for AI Functional Requirement; Generate properties in AIblock for input data, training data and testing data; If AIreq is called in a function, generate a postcondition with gr to corresponding ActivityN ode; Statistics of functions of the prototype tool

	Algorithm 5 Transform NFRs/AI requirements of system templates into SysML extensions
	Input: RNLReq
	Output: Model
	2:	if ST contains NFR quality then
	3:	Apply corresponding profile to Model;
	4:	if quality is attribute then
	5:	Translate ConstraintSentence and RangeSentence into OCL expressions with the attribute and
		generate ConstraintBlock;
	6:	Apply corresponding constraints to Block;
	7:	end if
	8:	if quality is deadline or WCET then
	9:	Apply corresponding NFR stereotype to Model;
	10:	Apply corresponding constraints to ActivityN ode;
	11:	end if
	12:	end if
	13:	if ST contains AIRequirement AIreq then
	14:	Apply MLComponent stereotype to corresponding Block AIblock;
	15:
	16:
	17:	Process AI NFRs with ConstraintRequirement;
	18:	if AIreq contains goal then
	19:	Translate GoalSentence into OCL expressions with the attribute and generate GoalRequire-
		ment gr;
	20:
	21:	end if
	22:	end if
	23: end for
	Function/Module	Description	Java Code Lines
	Intelligent Recommendation	IR4RNL module	1000+
	ReqTemplate Viewer	Requirement view module, an external interface for user operations	2000+
	ReqTemplate Controller	Requirement model control module	2000+
	RNLReq2SysML Mapper	RNL to SysML element mapping	1000+
	SysML Element Generator	Generate XML files corresponding to SysML model elements	1000+
	SysML Layout Visualizer	Generate the XML file corresponding to the SysML graphic layout	1500+

1: for each SystemTemplate ST in RNLReq do

Table 13 .

 13 Description of Case Studies

	Case	Description	Domain	Number of Requirements	Coverage
	Case-A	Autonomous Guidance, Navigation and Control (AGNC)	Space	280	257/280
	Case-B	Rocket control system	Space	146	141/146
	Case-C	Aircraft Air Pressurization System (AAPS)	Aviation	169	155/169

Table 14 .

 14 Comparison with other existing Tools

	Modeling Concepts	CM-Builder	DC-Builder	UMLG	aToucan	ABCD	RNLReq2SysML
	Class

  Accuracy metrics algorithm for clustering Input: Let I 1 , . . . , I t denote the set of ideal clusters, and let G 1 , . . . , G u denote the set of generated clusters. Let n ij be the number of common data points between I i and G j .

	Output: P recision,Recall,F -measure

1: For every pair (I i , G j ) 1 ≤ i ≤ t; 1 ≤ j ≤ u: 2: 3:

Table 15 .

 15 Description of Experimental data-set

	Case	Description	Domain	Number of Requirements	Number of standard terms
					(golden standard)
	Case-A	Autonomous Guidance, Navigation	Space	220	237
		and Control (AGNC)

Table 16 .

 16 Comparison of preliminary and final part-of-speech rules

	Length	Preliminary Part-of-speech Rules	Final Part-of-speech Rules
	Two	n+n, n+v, v+n	n+n, n+v, v+n, a+n, b+n, d+n
	Three	n+n+n, v+n+n, n+v+n, v+v+n	n+n+n, v+n+n, n+v+n, v+v+n, b+v+n, n+m+n, vn+vn+n
	Four	n+n+n+n, n+n+v+n	n+n+n+n, n+n+v+n, v+n+n+n, v+n+v+n, n+v+v+n,
			v+v+n+n, v+n+b+n
	Five	v+v+n+n+n, d+v+n+n+n, n+n+v+n+n	v+v+n+n+n, d+v+n+n+n, m+v+m+n+n, b+v+n+v+n,
			n+n+v+n+n, a+n+v+n+n
	Six	n+n+c+vn+n+n	n+n+c+vn+n+n, n+n+vn+c+vn+n, n+n+u+b+vn+n,
			vn+n+vn+c+vn+n, l+vn+k+n+vn+n, n+vn+u+n+vn+n

Table 17 .

 17 Top-10 cluster computation alternatives

	Grammatical Similarity Strategy	Semantic Similarity Strategy	Clustering Algorithm	Normalized F-measure
	Jaro-Winkler	None	Hierarchical Clustering	0.4149
	SimHash-Hamming Distance	Hownet	Hierarchical Clustering	0.4132
	Jaro	None	Hierarchical Clustering	0.4119
	SimHash-Hamming Distance	CiLin	Hierarchical Clustering	0.4105
	SimHash-Hamming Distance	None	Hierarchical Clustering	0.4104
	Block Distance	None	Hierarchical Clustering	0.4088
	Euclidean	None	Hierarchical Clustering	0.4081
	Jaro-Winkler	None	K-means	0.4004
	Levenshtein	None	Hierarchical Clustering	0.3998
	Jaro	None	K-means	0.3989

Table 18 .

 18 Good choices of the similarity measures and the clustering algorithm

	Strategy/Algorithm	Good Choices
	Grammatical Similarity Strategy
	Clustering Algorithm	Hierarchical Clustering

Jaro, Jaro-Winkler, SimHash-Hamming Semantic Similarity Strategy Semantic measures do not have a significant impact on clustering accuracy.

Table 19 .

 19 Bow-based feature extraction method requirement classification experiment results

	Combination Strategy		Experimental Results Exp 1 Exp 2 Exp 3	Exp 4	Exp 5	Average
		Precision(%)	94.52	94.44	96.09	93.24	94.85	94.63
	Bow + LR	Recall(%)	94.40	94.40	96.00	93.20	94.80	94.56
		F-measure(%)	94.41	94.36	96.02	93.20	94.81	94.56
		Precision(%)	94.27	96.93	97.28	94.75	96.60	95.96
	Bow + NB	Recall(%)	94.00	96.80	97.20	94.40	96.40	95.76
		F-measure(%)	93.98	96.80	97.19	94.34	96.39	95.74
		Precision(%)	94.44	93.66	96.53	93.73	94.50	94.57
	Bow + SVM	Recall(%)	94.40	93.60	96.40	93.60	94.40	94.48
		F-measure(%)	94.41	93.55	96.41	93.62	94.41	94.48
		Precision(%)	79.88	77.30	80.09	77.71	78.08	78.61
	Bow + KNN	Recall(%)	78.00	76.40	75.60	75.60	73.20	75.76
		F-measure(%)	77.63	75.99	74.86	75.44	72.98	75.38
		Precision(%)	87.39	90.62	92.88	88.88	93.06	90.56
	Bow + RF	Recall(%)	87.20	90.40	92.80	88.40	92.80	90.32
		F-measure(%)	87.17	90.38	92.80	88.46	92.81	90.32

Table 20 .

 20 TF-IDF-based feature extraction method requirement classification experiment results

	Combination Strategy		Experimental Results Exp 1 Exp 2 Exp 3	Exp 4	Exp 5	Average
		Precision(%)	97.28	96.81	98.42	97.65	96.02	97.24
	TF-IDF + LR	Recall(%)	97.20	96.80	98.40	97.60	96.00	97.20
		F-measure(%)	97.21	96.79	98.40	97.60	96.00	97.20
		Precision(%)	95.01	96.12	97.65	95.43	95.86	96.01
	TF-IDF + NB	Recall(%)	94.80	96.00	97.60	95.20	95.60	95.84
		F-measure(%)	94.78	95.97	97.60	95.14	95.58	95.81
		Precision(%)	96.46	96.46	99.22	97.62	98.45	97.64
	TF-IDF + SVM	Recall(%)	96.40	96.40	99.20	97.60	98.40	97.60
		F-measure(%)	96.40	96.36	99.20	97.60	98.40	97.59
		Precision(%)	93.67	94.13	94.45	92.60	92.69	93.51
	TF-IDF + KNN	Recall(%)	93.60	94.00	94.40	92.40	92.40	93.36
		F-measure(%)	93.55	93.96	94.41	92.42	92.37	93.34
		Precision(%)	88.11	90.61	90.46	88.13	93.35	90.13
	TF-IDF + RF	Recall(%)	88.00	90.40	90.40	87.60	93.20	89.92
		F-measure(%)	87.98	90.31	90.40	87.63	93.20	89.91

OMG. SysML. http://www.omgsysml.org

https://www.ansys.com/products/embedded-software/ansys-scade-suite

https://www.omgwiki.org/MBSE/doku.php?id=mbse:augmented

https://www.eclipse.org/papyrus/

https://www.eclipse.org/papyrus/

Acknowledgement Supported by the National Natural Science Foundation of China (62072233), Aviation Science Fund of China (201919052002), and the Fundamental Research Funds for the Central Universities (NP2017205).

A. PLAIN-TEXT INSTRUCTIONS FOR AUTO-GENERATED SYSML MODELS

The following is the plain-text instructions which have the same process and effect as the automated tool implementation. A system engineer can read these low-level, detailed instructions and build the model manually.