Biblio

Summary & Conclusions: The work described addresses assurance of a planning and execution software system being added to an in-orbit CubeSat to demonstrate autonomous control of that spacecraft. Our focus was on how to develop assurance of the correct operation of the added software in its operational context, our approach to which was to use an assurance case to guide and organize the information involved. The relatively manageable magnitude of the CubeSat and its autonomy demonstration experiment made it plausible to try out our assurance approach in a relatively short timeframe. Additionally, the time was ripe to inject useful assurance results into the ongoing development and testing of the autonomy demonstration. In conducting this, we sought to answer several questions about our assurance approach. The questions, and the conclusions we reached, are as follows: 1. Question: Would our approach to assurance apply to the introduction of a planning and execution software into an existing system? Conclusion: Yes. The use of an assurance case helped focus our attention on the more challenging aspects, notably the interactions between the added software and the existing software system into which it was being introduced. This guided us to choose a hazard analysis method specifically for software interactions. In addition, we were able to automate generation of assurance case elements from the hazard analysis' tabular representation. 2. Question: Would our methods prove understandable to the software engineers tasked with integrating the software into the CubeSat's existing system? Conclusion: Somewhat. In interim discussions with the software engineers we found the assurance case style, of decomposing an argument into smaller pieces, to be useful and understandable to organize discussion. Ultimately however we did not persuade them to adopt assurance cases as the means to present review information. We attribute this to reluctance to deviate from JPL's tried and true style of holding reviews. For the CubeSat project as a whole, hosting an autonomy demonstration was already a novelty. Combining this with presentation of review information via an assurance case, with which our reviewers would be unaccustomed, would have exacerbated the unfamiliarity. 3. Question: Would conducting our methods prove to be compatible with the (limited) time available of the software engineers? Conclusion: Yes. We used a series of six brief meetings (approximately one hour each) with the development team to first identify the interactions as the area on which to focus, and to then perform the hazard analysis on those interactions. We used the meetings to confirm, or correct as necessary, our understanding of the software system and the spacecraft context. Between meetings we studied the existing software documentation, did preliminary analyses by ourselves, and documented the results in a concise form suitable for discussion with the team. 4. Question: Would our methods yield useful results to the software engineers? Conclusion: Yes. The hazard analysis systematically confirmed existing hazards' mitigations, and drew attention to a mitigation whose implementation needed particular care. In some cases, the analysis identified potential hazards - and what to do about them - should some of the more sophisticated capabilities of the planning and execution software be used. These capabilities, not exercised in the initial experiments on the CubeSat, may be used in future experiments. We remain involved with the developers as they prepare for these future experiments, so our analysis results will be of benefit as these proceed.

The National Airspace System (NAS), as a portion of the US' transportation system, has not yet begun to model or adopt integration of Artificial Intelligence (AI) technology. However, users of the NAS, i.e., Air transport operators, UAS operators, etc. are beginning to use this technology throughout their operations. At issue within the broader aviation marketplace, is the continued search for a solution set to the persistent daily delays and schedule perturbations that occur within the NAS. Despite billions invested through the NAS Modernization Program, the delays persist in the face of reduced demand for commercial routings. Every delay represents an economic loss to commercial transport operators, passengers, freighters, and any business depending on the transportation performance. Therefore, the FAA needs to begin to address from an advanced concepts perspective, what this wave of new technology will affect as it is brought to bear on various operations performance parameters, including safety, security, efficiency, and resiliency solution sets. This paper is the first in a series of papers we are developing to explore the application of AI in the National Airspace System (NAS). This first paper is meant to get everyone in the aviation community on the same page, a primer if you will, to start the technical discussions. This paper will define AI; the capabilities associated with AI; current use cases within the aviation ecosystem; and how to prepare for insertion of AI in the NAS. The next series of papers will look at NAS Operations Theory utilizing AI capabilities and eventually leading to a future intelligent NAS (iNAS) environment.

This paper proposes an intelligent functional architecture for an advanced launch site system that is composed of five parts: the intelligent technical area, the intelligent launching region, the intelligent flight and landing area, the intelligent command and control system, and the intelligent analysis assessment system. The five parts consist of the infrastructure, facilities, equipment, hardware and software and thus include the whole mission processes of ground and launch systems from flight articles' entry to launch. The architectural framework is designed for the intelligent elements of the parts. The framework is also defined as the interrelationship and the interface of the elements, including the launch vehicle and flight payloads. Based on the Internet of Things (IoT), the framework is integrated on four levels: the physical layer, the perception layer, the network layer, and the application layer. The physical layer includes the physical objects and actuators of the launch site. The perception layer consists of the sensors and data processing system. The network layer supplies the access gateways and backbone network. The application layer serves application systems through the middleware platform. The core of the intelligent system is the controller of the automatic control system crossing the four layers. This study builds the models of the IoT, cloud platform, middleware, integrated access gateway, and automatic control system for actual ground and launch systems. A formal approach describes and defines the architecture, models and autonomous control flows in the paper. The defined models describe the physical objects, intelligent elements, interface relations, status transformation functions, etc. The test operation and launch processes are connected with the intelligent system model. This study has been applied to an individual mission project and achieved good results. The architecture and the models of this study regulate the relationship between the elements of the intelligent system. The study lays a foundation for the architectural construction, the simulation and the verification of the intelligent systems at the launch site.

Many accidents occurred frequently in aerospace applications, traditional software reliability analysis methods are not enough for modern flight control software. Developing a comprehensive, effective and intelligent method for software fault diagnosis is urgent for airborne software engineering. Under this background, we constructed a fault diagnosis expert system for flight control software which combines software failure mode and effect analysis with software fault tree analysis. To simplify the analysis, the software fault knowledge of four modules is acquired by reliability analysis methods. Then by taking full advantage of the CLIPS shell, knowledge representation and inference engine can be realized smoothly. Finally, we integrated CLIPS into VC++ to achieve visualization, fault diagnosis and inference for flight control software can be performed in the human-computer interaction interface. The results illustrate that the system is able to diagnose software fault, analysis the reasons and present some reasonable solutions like a human expert.

Electro-hydraulic servo actuation system is a mechanical, electrical and hydraulic mixing complex system. If it can't be repaired for a long time, it is necessary to consider the possibility of occurrence of multiple faults. Considering this possibility, this paper presents an extended Kalman filter (EKF) based method for multiple faults diagnosis. Through analysing the failure modes and mechanism of the electro-hydraulic servo actuation system and modelling selected typical failure modes, the relationship between the key parameters of the system and the faults is obtained. The extended Kalman filter which is a commonly used algorithm for estimating parameters is used to on-line fault diagnosis. Then use the extended Kalman filter to diagnose potential faults. The simulation results show that the multi-fault diagnosis method based on extended Kalman filter is effective for multi-fault diagnosis of electro-hydraulic servo actuation system.

Recent attention to aviation cyber physical systems (ACPS) is driven by the need for seamless integration of design disciplines that dominate physical world and cyber world convergence. System convergence is a big obstacle to good aviation cyber-physical system (ACPS) design, which is due to a lack of an adequate scientific theoretical foundation for the subject. The absence of a good understanding of the science of aviation system convergence is not due to neglect, but rather due to its difficulty. Most complex aviation system builders have abandoned any science or engineering discipline for system convergence they simply treat it as a management problem. Aviation System convergence is almost totally absent from software engineering and engineering curricula. Hence, system convergence is particularly challenging in ACPS where fundamentally different physical and computational design concerns intersect. In this paper, we propose an integrated approach to handle System convergence of aviation cyber physical systems based on multi-dimensions, multi-views, multi-paradigm and multiple tools. This model-integrated development approach addresses the development needs of cyber physical systems through the pervasive use of models, and physical world, cyber world can be specified and modeled together, cyber world and physical world can be converged entirely, and cyber world models and physical world model can be integrated seamlessly. The effectiveness of the approach is illustrated by means of one practical case study: specifying and modeling Aircraft Systems. In this paper, We specify and model Aviation Cyber-Physical Systems with integrating Modelica, Modelicaml and Architecture Analysis & Design Language (AADL), the physical world is modeled by Modelica and Modelicaml, the cyber part is modeled by AADL and Modelicaml.