Titulo Estágio
A SW ARCHITECTURE FOR CLOSED-LOOP SIMULATION OF A SUN-SYNCHRONOUS SATELLITE
Áreas de especialidade
Engenharia de Software
Sistemas Inteligentes
Local do Estágio
Coimbra, Taveiro
Enquadramento
Systems do not exist in isolation; they interact with the environment and with other systems. Still, in many, if not the majority, of cases, these dependencies are ignored when validating and testing software and integrated electronic equipment. It is true that in many situations, this is a sufficient approach and that therefore the system under test can effectively validated in open loop. In other cases, however, particularly when dealing with control systems and other alike, open loop testing is insufficient because only hardly could one effectively and efficiently define a sufficient combination of inputs and expected outputs. Such systems require closed-loop testing and that entails simulating external systems the system under test interacts with, the environment where the system operates and possibly also the system dynamics.
The work proposed here aims at studying and implementing a software architecture for closed loop simulation. For this study we propose using a Sun-synchronous satellite to derive the requirements for the closed-loop SW architecture and to validate it. Because control systems rely upon a common set of architectural concepts, the SW architecture resulting from this study should be valid to a wide range of specific applications - i.e. the particular instantiation will encompass selected aspects of a Sun-synchronous satellite, but the potential uses of the architecture will not be limited to this case alone.
Capturing and implementing all the aspects of a Sun-synchronous spacecraft dynamics and environment is a task that exceeds by far the feasible scope for a master thesis. Therefore, the proposed work is limited to a sub-set of the aspects of the simulated system that is sufficient to define and validate the SW architecture. A first enumeration of this subset is presented in §1, but the student has the flexibility to further refine the aspects to be modelled and implemented. Selecting a consistent and sufficient set of system aspects is a key task the student shall fulfil - this task will demonstrate the student's ability to make the best with limited resources (i.e. his own time), which is a key aspect in engineering. The analysis and trade-offs made should be well-described in the master thesis document.
Objetivo
1.3. PROPOSED WORK LOGIC
This section presents the high-level structure of the proposed work logic. This is provided as a guideline and the student has the freedom to refine it in the scope of his/hers work.
1.3.1 PRELIMINARY STUDIES
There are several software architecture paradigms, namely: object oriented, service oriented and data oriented. Each of these paradigms is supported by one or more middleware technologies, which have bindings to one or more programming languages. A specific software architecture can rely in one or more paradigms. When multiple paradigms are combined, one of them usually prevails over the others.
The purpose of this activity is to analyse different architecture paradigms and the middleware supporting them, as to ultimately select one or a given set of paradigms for the simulation architecture implementation. This initial step is important because not all design constructs are feasible in all paradigms. The selected paradigms and middleware shall effectively address the needs of a closed-loop simulator containing both continuous and discrete models. The paradigms and middleware analysed, along with the evaluation criteria, the selected technologies and the selection justification should be concisely described in the master thesis document.
1.3.2 SIMULATION ARCHITECTURE DEFINITION
After selecting the architectural paradigms, the student shall design a simulation architecture compliant with those paradigms and compliant with the closed-loop simulation requirements. The architecture shall be described in UML and shall include:
• The Static View: describing how components are organised, where the interfaces are and how simulation models can be deployed in the architecture.
• The Dynamic View: describing how the architecture operates in run-time. A key aspect is to determine, and then design, whether the architecture is predominantly cyclic or predominantly reactive. This aspect plays an important role on the discretisation and execution of simulation models, namely of continuous models.
The architecture description should be included in the master thesis document. A description of the design trade-offs and choices should also be included in the document.
1.3.3 SIMULATION ARCHITECTURE VALIDATION
The student shall validate the proposed simulation architecture by instantiating it with a particular case study. For this purpose, we propose the use of the Sun-synchronous satellite described in §1.
It is recommended that the architecture validation runs in parallel with the architecture definition, such that flaws and limitations uncovered by the validation are quickly incorporated in the design. The student should however assure that the architecture has a general purpose and is not limited to the specific needs of the case study used to validate it.
For validating the architecture, the student can use models developed in a high-level modelling language. A collection of simple models, developed in OpenModelica, will be provided as input. These models cover a limited set of the aspects of a Sun-synchronous satellite. The student may extend these models, as to complete a closed loop system, but the main purpose of the task at hand is the simulation architecture, not the models from OpenModelica.
The outcomes of the simulation architecture validation shall be concisely described in the master thesis document. The document should also mention limitations the student was unable to solve within the available time frame and possible future work.
Plano de Trabalhos - Semestre 1
O Estagiário é a parte responsável pela execução das atividades aqui propostas contando para tal com o apoio do Orientador Académico e do Orientador Industrial. O contexto do trabalho proposto é apresentado em §1.1 - o estagiário não terá que elaborar o modelo de simulação, mas sim implementar uma arquitetura que o suporte. Um, primeiro esboço dos requisitos a que a arquitetura de SW deve dar resposta é apresentado em §1.2. A visão geral sobre a organização do trabalho proposto é apresentada em §1.3. O Estagiário é neste âmbito responsável por produzir os seguintes artefactos:
• S1.1: Análise de requisitos atendendo aos aspetos funcionais, de controlo e de performance que a arquitetu-ra de simulação deverá suportar - um dos aspetos chave a endereçar é o controlo de tempo;
• S1.2: Análise de prós e contras de paradigmas arquiteturais incluindo arquiteturas: orientadas a objetos, orientadas a mensagens, orientadas a dados, híbridas, etc. Esta componente do trabalho incluí também a análise de funcionalidades e constrangimentos de diferentes paradigmas para o controlo de tempo de simu-lação - e.g. análise de tecnologias tais como: CORBA, HLA/IEEE1516, EPICS, DDS, etc.;
• S1.3: Elaboração do primeiro esboço da arquitetura, incluindo vistas estrutural e dinâmica para validar a viabilidade do paradigma/tecnologia selecionado em S1.2;
Plano de Trabalhos - Semestre 2
• S2.1: Desenvolvimento de um protótipo da arquitetura de simulação - durante esta tarefa o estagiário poderá reequacionar ou refinar a abordagem a seguir;
• S2.2: Implementação de um simulador usando a abordagem previamente selecionada e refinada - nesta fase a implementação do código e refinação do desenho detalhado decorrem em paralelo.
• S2.3: Relatório Final de Estágio, sintetizando o problema proposto, e se adequado o estado da arte no tema proposto, descrevendo a solução desenvolvida pelo Estagiário e os principais problemas que este encontrou e a forma como os superou;
• S2.4: Apresentação Final de Estágio sintetizando o trabalho desenvolvido e os resultados alcançados. O Es-tagiário deverá fazer uma apresentação pública nas instalações da CRITICAL Software.
Cabe ao Orientador Académico definir os moldes nos quais e os conteúdos essenciais que o Estagiário deverá endereçar no Relatório Final de Estágio.
Condições
O Orientador Académico e o Orientador Industrial são responsáveis por acompanhar o Estagiário garantindo que este tem as condições necessárias para a execução do estágio, incluindo acesso a instalações e materiais necessários para o efeito. A avaliação do Estágio é da responsabilidade da Instituição de Ensino Superior, sendo o Orientador Industrial responsável por prestar informações requeridas por esta para esse efeito.
A bolsa de estágio oferecida é de 450 euros.
Orientador
Nuno Pedro Silva
nsilva@criticalsoftware.com 📩