Use of the simulation along the product life cycle

System Engineering process starts from the top level requirements analysis which flows into functional analysis and allocation. Tailored to M&S approach, inputs and outputs become simulation parameters that are strictly connected with hardware and software. The main idea is “model-simulate- fix-test-iterate” that help to identify deficiency in hardware and software bugs. Functional analysis helps to determine what the system can do and it ends with the allocation of the lowest level functions to the elements that conduct those functions. The elements can be subsystems, assemblies or components; it depends on the current iteration of the process. Architecture and interface among elements result in blocks diagrams or similar tools. From the previous work, designers can trace functional and performance, interface and design requirements. System requirements should be sufficiently detailed to provide design and, also, verification criteria. To simulate system functions and elements the models substitute the relative blocks and relationships in the defined architecture; engineering and physical parameters characterize each model. Hardware devices, software parts and interface can progressively replace models with the simulation loop as well as the system is mature, eventually resulting in SIL, CIL, HIL (see paragraph 1.4).In the alternate iteration of design and verification processes, the final physical architecture comes in the light and the simulation sessions on it bring to achievement of the functional and performances requirements. For modeling and simulation, the architecture shall always be sufficiently detailed to verify that the design meets the requirements.

Summarizing, the support of the M&S based techniques as part of SE consists of two “loop”:

 The design loop in which an iterative comparison between the evolving design and the system

function occurs for ensure the goodness of the design wrt each function. Using simulation, it is continuously possible to monitor that the design meets the requirements

 The verification loop in which tests and other methods ensures that the design meets the operational needs according to the requirements analysis. Again, simulation helps to track and check the key parameters and monitor their evolution according to the expected ones.

Table 1 shows the use of the simulation along the product life cycle. [5]. The use of system simulation evolves through system level requirements definition, analysis and design trade-offs, then to AIT at subsystem and system level, and finally to training and support for operations. Simulation should be used as key element to support a wide range of engineering and operational activities during the lifecycle of a program. These activities are:

 Analysis, definition and validation of system and technical requirements.

 Validation that the design (from an electrical, thermal, mechanical, operational, etc. point of

view) fulfils the high-level (mission and system) performance requirements.

 Software verification and validation.

 Development of GSE and test procedures.

 Prediction of system performance.

 Control centre and crew operator training.

 Operations procedure development and validation.

23

Product Life Cycle Engineering and

Operations activities

Phase 0 Phase A Phase B Phase C

Phase D Phase E Phase F

Feasibility and Performance Analysis/Trade- Offs Concurrent Design Activities Requirements Specification Concurrent Design Activities System & Mission Analysis Design Verification

System Interfaces and End-to- End Design Trade-off System and Mission performance verification

System Interfaces and End-to- End Design Trade-off Functional (Subsystem) V&V Interfaces and End- to-End AIV OBSW AIV OBSW Spacecraft Qualification & Acceptance Virtual AIV AIV SVTs Ground Segment Qualification & Acceptance MCS Testing Operations Procedure Validation SVTs System Qualification & Acceptance AIV SVTs System Maintenance (e.g. Software) Training & Operations Mission Control Team Training On-Going Mission Control Team Training OBSW Patch and Ops Procedure Validation Investigation of Disposal options

Table 1: System simulation in Product Life Cycle [5]

To develop a simulation successfully, designer must clearly describe its intended use (what?, why? and how?). Figure 6 shows the general uses of simulation to support SE. From this figure, it is clear how the use of simulation changes over a traditional program’s life cycle. In applications, you can repeat each use for a spiral or incremental development.

24

Modeling &Simulation Modeling &Simulation System design Functional Analysis Requirements analysis Synthesis Requirements loop Design loop Drive Influence Drive Refine Drive adjust

Figure 6: System development based on simulation

For simulation-based development, simulation is used in each development step to represent the entire system and, if required, each component. In either case, the models represent the system’s components, and you can replace these models with software or hardware in the loop (SIL or HIL).

Figure 7: Use of the simulation in the product life cycle [7]

As shown in Figure 7, simulation based development can be split in stages:

1. System analysis and requirements allocation: simulation helps to predict the performances of concepts and designs. It is the basis for operational analyses that allow understanding the capability of a potential system. These can be simulations on specific part or function or on

25

the whole system. Analysis from this type of simulations provides a fully traceable component requirements and detailed estimates of performance. A lot of simulation runs are needed requiring that each run is as fast as possible independently by the level of detail of system models as well as the environment models. The simulation should output values for technical performance measures (key parameters) from evaluations of each design. The result is a clear statement of a component’s expected contribution to these key parameters. Simulator is flexible enough in order to change easily the configurations.

2. Design verification: it means to define and trace functions or parts, allocate tasks, evaluate alternatives, in order to extract the preferred configuration. The simulation serves to demonstrate that the design fit the requirements. Simulation-based development uses an incremental approach to development supported by component models, prototypes, hardware and software deliveries, and simulations with hardware and software in the loop. Simulation verifies the design to ensure the components work as expected, are integrated correctly, and meet system requirements. Traditionally, designs use margins to handle large, complex programs that can’t be tested in their full operational configuration without a lot of expense and risk. Space programs are an example. Often, measuring a system’s design margins is difficult, as is tracking key parameters progress and the effect on system-level risk. In this case, your design may be too conservative (costly). To address these issues with simulation, the designer evaluates the key parameters for systems and components in each scenario or varies the key parameters within a component and observe the impact on its performance and on the performance of other system’s components. High integrated tools are fundamentals to simulate system with different components and different level of abstraction and detail. Specific techniques allow comparing the results to other representations of the system.

3. Build and component test: it means to define the subsystems and their components and progressively testing ready software parts and hardware devices. System analysis and requirements allocation establish requirements from the top down. Component build and test predicts performance from the bottom up by estimating a component’s performance as it integrates into the system. It can also handle new situations, such as a new environmental condition, altered component design, or operation at the comer of the performance envelope. This performance must be traceable to the system requirements. During preliminary design, designer must analyze different alternatives using detailed component simulations and input the characteristics of promising alternatives into tools devoted to evaluate the architecture. Without an integrated tool, this process is slow and laborious. Finally, the two processes shall be combined first using detailed component models with a fixed scenario and then incorporating the performance of component models into a simulator for system analysis and requirements. To do so, high detailed simulation components (or models) shall be integrated into a system-level simulation (integrated simulation environment).

4. Integration and verification: it consists of the integration of the whole system. Simulation provides the environment but differs in quantity. Build and component test (above) requires more because the latter stimulates and accepts responses from very low-level components. As more components become available, simulation decreases because real hardware and software replace it. During integration the system is the test object put in the simulation loop to ensure the items are integrated correctly, work properly, and meet the system’s operational requirements. Integration and verification test follows this process by using components shown to meet component requirements, which enables the system to meet system requirements. The simulation results serve now to measure the performance of a system and its components against operational needs: pay attention that, in this stage, it is not of interest evaluate if the components meet performance requirements but the simulation shall verify that

26

the system design meets operational requirements. All the interfaces shall be active and become parts of the simulation because each component is connected through the natural component interface with the part of a simulation that uses a system’s true data to work with the component : summarizing, the simulator must work in real time to support hardware-in- the-loop. Moreover, if applicable, the simulation should be able to operate in a distributed manner so geographically disperse system components can work together. This means the simulation’s execution must be able to meet two requirements at the same time: it must support simulations of components that are not involved in the test and it must interconnect components separated from the local system simulation. Therefore, integration and verification test could require distributed, real-time simulations to integrate geographically dispersed components or subsystems (distributed executive).

5. Development and Operational Testing and Training: this stage foresees test in the real world; simulation is used to stimulate articles for test, connect test players, and provide the external environment for a test object. Simulation also helps to plan tests, make decisions and transform the results in settable parameters for the operations. Three abilities are required for the test: planning test, providing real time support during the test and training.

 Test planning and analysis. Support for testing includes planning for a test, predicting the test before it starts, and interpreting results to determine what happened and to relate results to the operational system’s configuration and environment. If system components are not available, simulation replaces them. Simulation also provides or supplements the test environment. Test planning involves running simulations to determine component requirements that will meet a testing objective. It defines the best configuration for the test, including the component surrogates. The first output of the analysis is a set of go/no- go decisions to ensure the meeting of test objectives. The second output extrapolates the test system’s performance to an operational system’s likely performance by interpreting the results in terms of the design. Simulation-based development predicts the results before a test. If the test meets predictions, simulation has accurately captured system performance. If the predictions are wrong, the test may have occurred outside nominal conditions or a review to update the understanding of component performance in the simulation and, probably, in the design database is needed. Test planning and analysis require simulating the test conditions and articles in the test environment to reduce risk of failure. Therefore, the simulation must be able to model the test environment (models of test equipment). Models of the test environment and the systems shall consistently represent the real world, to relate simulated or test behavior to the operational system’s behavior. Most tests will use GSE elements that produce behavior similar but not identical to the designed components. Simulation also must be able to relate overall test results to operational performance (translate simulated to actual system performance).

 Test support. Test support includes full, formal, developmental, and operational tests of

the system, with extensive customer participation. In test planning and analysis, integrated distributed simulations run to verify the test can succeed and confirm conditions under which the test should be aborted or successfully completed. The test itself uses this data and real-time simulation to support decisions that control it. The simulation handles four activities:

o Comparing real-time inputs on the test with nominal values

o Simulating inputs from external systems or components that don’t have surrogates

available

o Controlling the test environment and data systems o Collecting and recording data

27

Test support requires distributed, real-time simulations to help test rehearsals in nominal or off nominal conditions, to verify the test system’s performance, and to support the real- time testing and data collection (distributed real-time executive). To validate test equipment, simulation must be able to connect to the equipment, inject test signals and simulated data, accept outputs, and compare outputs to results from simulating the system in a similar condition (test equipment interface and control). For test rehearsals, it must connect to each piece of test-control equipment and simulate in real time all normal and abnormal test conditions. It also should be able to pause, allow rollback and restart, and automatically collect data for comparison to other rehearsals and test predictions (scenario control). Finally, simulation must capture real-time data; process that data quickly; compare it to the outputs of simulation models, previous runs, or precomputed limits; and present the results (data capture and analysis). Of course, it also must be able to create a wide variety of scenarios (scenario generation).

 Training activities. To get good results, the operator shall be skilled. For this reason the

operator shall be train people for operational testing and for follow-on operations. A training simulation must be able to clearly explain system options to decision makers and quickly help new people understand the system, as well as issues such as system requirements. Simulation should contain scenarios to illustrate other, more complex aspects of the operation, probably in a library of situations that a person can recall and run-or display if using a postprocessor (selectable scenarios). The user should control the scenario’s speed by pausing, reversing, and altering selected views (scenario control). Other scenarios should illustrate key aspects of the operation to explain design decisions, system performance, and similar issues. For critical explanations, flexible scenarios allow the users to change them and then run a simulation based on the modified scenario (flexible scenarios). Moreover, the user’s console controls the simulation, so the latter can work with the operational software’s exercise and training mode (scenario control). Finally, the simulation must include in the report the ability to analyze performance (feedback) and provide tutoring to improve it-possibly through hyperlinks from the report (tutoring).

In document Design and verification of Guidance, Navigation and Control systems for space applications (Page 49-54)