A Function to Data Matrix (FDM) Approach for Mission Variables Consideration

Precise control of technical system variables in industrial processes and manned and unmanned missions is critical as their results should be achieved plenty. This takes place in Control Rooms (CR) where Operators make decisions based on the large amount of received data. This work proposes a method for weighting variables of a technical system based on their impact on the mission objectives. The relationships between variables and mission functions are defined using a Function to Data Matrix (FDM) in order to allow Operators to determine their criticality. The proposed method was applied for the mission control of the Racing Solar Vehicle Primavera1 which participated in the World Solar Challenge (WSC) 2013 in Australia.


Introduction
In a Control Room (CR) or Mission Control Center (MCC) Operators control a Technical system trying to reduce unwanted variabilities related to its dynamics and manage its operational phases in order to get expected results. In steel processing facilities, nuclear power plants, orbital and planetary missions or top end racing vehicles, there are several components working together as subsystems, interacting each other and performing a sequence of steps. Proper operation of those components depends on accurate measuring, monitoring and deep knowledge about the process and large amounts of data are processed to make decisions about mission development. Since objectives of the mission define the nature of implemented technical systems, Operators should be aware of data that have direct impact with mission operations, especially if they can not only monitor but influence them by changing system parameters. As the systems become more complex, the number of underlying information flowing between subsystems or devices increases, masking any behaviour out of which Operators must be aware of. Analysing a mission with a proposed Function to Data Matrix (FDM), data can be linked with their role and relevance to mission functions based on objectives to be achieved. Operators can use FDM to decide if any system variable impacts in one or more functions of the mission and its relevance based on Variable Relevance Indicator (VRI) and Function Relevance Indicator (FRI).

Previous studies and models
Several studies have focused on developing mission analysis methods to improve mission execution by studying which information should be presented to operators and how to show it. Most developed work is on space missions like Space Mission Analysis and Design (SMAD), implemented by NASA [1] but it can be adopted in every process requiring a CR as well. Non-Parametric methods like Expected Value of Displayed Information (EVDI) and Expected Value of Revealed Information (EVRI) were used. Besides, the amount of data actually used by Operators during decision making can be measured using probabilistic methods. Since levels of expertise are different between Operators, the results of the method may vary and several iterations may be performed [2]. Ecological Interface Design (EID) defines semantic fields as a Work Domain Analysis (WDA) in a constrained base style, and it is especially useful for non-expert users with no in-deep knowledge about the technical system [3] [4]. Canadian BlueSky Solar Car Team implemented an EID Approach for their racing Vehicles [5]. The proposed approach is focused on Functional Structure as a tool for better understanding of system internals linked to mission basic functions that must be covered to get satisfactory results and objectives accomplishment.

Approach based on Function to Data Matrix (FDM) applied to Mission Control Rooms
The proposed approach, presented in Fig. 1, considers four steps. It starts analysing the internal of the technical system using documentation such as datasheets, mechanical and electrical plans, and software. Then, general function carriers are defined by Reverse Engineering methods. Also, a mission analysis is required, starting from a statement and being complemented by additional documentation as Product Design Specifications (PDS), regulations or manuals. Finally, the FDM is created.

Step 1. Mission Essential Analysis.
The Mission Description is denoted by context, required and available resources, tasks to be performed and timelines. The purpose of the mission task execution and its expected results can be defined as Mission Objectives or Mission Goals. Although they are set out qualitatively, they can be measured in a quantitative way defining performance indicators or Success Criteria Indicators, showing the degree of compliance or failure of the tasks.

Step 2. Goal to Function Analysis.
Certain functions must be completed in a specific order and in its entirety. They are related to operational capabilities, devices and tasks to be performed, which are designed for mission execution by the use of a Goal to Function Tree (GFT) [6]. The highest level function to be covered (Mission Goal) can be broken down into lower level functions. While going down the tree, functions become simpler and give detailed indications on how higher level functions should be performed. If functions cannot be broken, they become Basic Functions [7] and they appear at the end of each branch.

Step 3. Technical System Analysis: Functional Diagram (FD).
A simple way to analyse technical systems is through the division of its parts and definition of interactions between them as Functional structures manage it [8]. Generally used as product design tool, could be used to analyse existing systems by the use of Function Structure Transformation (through definition of basic classes and functions) [9] as Reverse Engineering process does [10] and starting from a physical block diagram of the process obtained by observation [11]. In a FD the interactions (Matter, Energy and Information) between each subsystem emerges. From the point of view of the Operators, certain information cannot be observed or does not exist. Only emerging information flows are visible to them, and interact with the environment. By themselves, underlying information flows can be used as performance indicators for a particular subsystem adding a function carrier block called Sensor. A sensor does not transform neither incoming energy nor matter, but quantifies crossing energy or matter through an information flow, which can be conducted outside the FD, thus, making it explicit to Operators. Theoretically, a Sensor does not disturb Energy or matter flows, but, some aspects of adding a Sensor must be considered: Feasibility. Knowledge, tools and skills should be available to install a sensor. If not, consider the possibility to generate or create them within time, technical and budget constraints.
Need. As success criteria, is the information necessary for the fulfilment of the mission objectives and to obtain performance indicators of them?
Degradation. Would installed sensors affect the technical system performance in terms of power consumption and signal distortion? If they would, they affect mission objectives accomplishment.
In the context of a Technical System, Information Flows lead Raw Data and a post-processing of these data, expressed as variables, is required. Then, relationships between variables are created as Mission Information and shown to Operators using a Graphic User Interface (GUI) or Human Machine Interface (HMI

Step 4. Function to Data Matrix (FDM).
Basic functions (rows) and Mission Variables (columns) are linked in FDM by Variable Relevance Indicator (VRI), denoted by P fj , and Function Relevance Indicator (FRI), denoted by P vj . VRI ranks certain variable in terms of its relevance along and within mission functions, and it is presented in Eq. 2 FRI shows to Operators which function requires especial attention by the amount of data related to it, and it is presented in Eq. 3 It is required that Operators define the degree of relationship between both, using a relationship descriptor kfjvj with four categorical values: kfjvj=0 or Null, kfjvj=1 or Weak, kfjvj=3 or Medium and kfjvj=9 or Strong. Both VRI and FRI are normalized.

Case study: Racing solar electric vehicle Primavera1
A Solar Electric Vehicle (SEV) harvests irradiated energy from the sun using a Photovoltaic (PV) array. High Electrical and Aerodynamic efficiencies must be accomplished due to race conditions. Then, constant monitoring of vehicle variables and strategy should be done aboard an escort vehicle, forcing Operators to receive and analyse large amounts of information in a limited time. Primavera1, shown in Fig.2, is the first Colombian solar car competed during World Solar Challenge (WSC) 2013 in a 2505km self-powered travel.

Mission statement for WSC.
The WSC mission statement is defined as Departing from city of Darwin and arriving to the city of Adelaide in less than 50 hours in a SEV [12]. Then, Primary Objective is to Transport a Driver from Darwin to Adelaide in a Solar Electric Vehicle taking into account all restrictions and conditions stated in the WSC Event Regulations Document (as complementary Mission Description). Success Criteria is measured by time it takes to cross the finish line, with a reference maximum time limit of 50 hours.

Goal to Function Tree (GFT).
In the simplified GFT for the mission, presented in Fig.3, highlighted boxes show Basic Functions. Due to nature of the race and Technical specifications of the Vehicle, most of the functions are focused on collect, store and manage available energy resources (Driving Strategy).

Primavera 1 Functional Diagram (FD).
For this Solar Vehicle a simplified Structural Analysis is presented in Fig. 4, Vehicle uses a communication bus based on CANBusV2.0, and both Control commands and system data are sent to MCC trough a RS232-Based Radio Frequency Module. Data packages between devices are represented by information flows in Fig.4, not the actual Bus layout. An additional current integrator and voltage sensor, g 1 was added between the battery pack leads and the ESC Module, due to mismatch lectures from battery current integrator.

Function to Data Matrix (FDM).
A summary of Proposed FDM is presented in Table 1. For Primavera1, 279 variables were identified. kf j v j values were obtained by Expert Engineers from Photovoltaics, Electronics and Computational Mechanics areas. Solar Array to Solar ECU, Battery-Pack to Solar ECU and Solar ECU to Electronic Speed Controller were selected as they are representative in the vehicle. Also, information flow, from g 1 sensor, is included in the analysis.

Conclusions
FDM can be useful to Operators as a tool for easy understanding of the technical system in context of mission goals and requirements. All relevant information is shown in a simple way and can be used as a Product Design Specification for GUI designers and Operators during Mission Execution. FDM can be hard to implement by hand in high complex systems so computer aided FDM tool approach will be implemented for future work. Several interpretations can be made while constructing GFT and FD. So, more than one iteration of the method is recommended. Both VRI and FRI values depends on the amount of analysed variables and basic functions. It shows no absolute values, but relative to each other, changing as the analysed amount of variables changes.
There is no differentiation between $\alpha$ values shown in VRI for each type of variable, so an additional ponderation factor is required. This is especially evident with Alarms and Flags Variables.
Operational stages analysis will be also implemented in the future.