ENGENHARIA DE SISTEMAS APLICADA AO DESENVOLVIMENTO

PDF DOWNLOAD: ENGENHARIA DE SISTEMAS APLICADA AO DESENVOLVIMENTO DO EQUIPAMENTO DE SUPORTE EM TERRA- GSE

sid.inpe.br/mtc-m21b/2017/02.22.14.03-TDI

ENGENHARIA DE SISTEMAS APLICADA AO DESENVOLVIMENTO DO EQUIPAMENTO DE SUPORTE EM TERRA – GSE

Guilherme Venticinque

Dissertação de Mestrado do Curso de Pós-Graduação em Engenharia e Tecnologia Espaciais/Engenharia e Gerenciamento de Sistemas Espaciais, orientada pelo Dr. Geilson Loureiro, aprovada em 27 de fevereiro de 2017.

URL do documento original: <http://urlib.net/8JMKD3MGP3W34P/3NDGR8B>

INPE

São José dos Campos 2017

PUBLICADO POR:

Instituto Nacional de Pesquisas Espaciais – INPE Gabinete do Diretor (GB)

Serviço de Informação e Documentação (SID) Caixa Postal 515 – CEP 12.245-970

São José dos Campos – SP – Brasil Tel.:(012) 3208-6923/6921

Fax: (012) 3208-6919 E-mail: [email protected]

COMISSÃO DO CONSELHO DE EDITORAÇÃO E PRESERVAÇÃO DA PRODUÇÃO INTELECTUAL DO INPE (DE/DIR-544): Presidente:

Maria do Carmo de Andrade Nono – Conselho de Pós-Graduação (CPG) Membros:

Dr. Plínio Carlos Alvalá – Centro de Ciência do Sistema Terrestre (CST)

Dr. André de Castro Milone – Coordenação de Ciências Espaciais e Atmosféricas (CEA)

Dra. Carina de Barros Melo – Coordenação de Laboratórios Associados (CTE)

Dr. Evandro Marconi Rocco – Coordenação de Engenharia e Tecnologia Espacial (ETE)

Dr. Hermann Johann Heinrich Kux – Coordenação de Observação da Terra (OBT) Dr. Marley Cavalcante de Lima Moscati – Centro de Previsão de Tempo e Estudos Climáticos (CPT)

Silvia Castro Marcelino – Serviço de Informação e Documentação (SID) BIBLIOTECA DIGITAL:

Dr. Gerald Jean Francis Banon

Clayton Martins Pereira – Serviço de Informação e Documentação (SID) REVISÃO E NORMALIZAÇÃO DOCUMENTÁRIA:

Simone Angélica Del Ducca Barbedo – Serviço de Informação e Documentação (SID)

Yolanda Ribeiro da Silva Souza – Serviço de Informação e Documentação (SID) EDITORAÇÃO ELETRÔNICA:

Marcelo de Castro Pazos – Serviço de Informação e Documentação (SID) André Luis Dias Fernandes – Serviço de Informação e Documentação (SID)

sid.inpe.br/mtc-m21b/2017/02.22.14.03-TDI

ENGENHARIA DE SISTEMAS APLICADA AO DESENVOLVIMENTO DO EQUIPAMENTO DE SUPORTE EM TERRA – GSE

Guilherme Venticinque

URL do documento original: <http://urlib.net/8JMKD3MGP3W34P/3NDGR8B>

INPE

São José dos Campos 2017

Dados Internacionais de Catalogação na Publicação (CIP)

Venticinque, Guilherme.

V565e Engenharia de sistemas aplicada ao desenvolvimento do equipamento de suporte em terra – GSE / Guilherme Venticinque. – São José dos Campos : INPE, 2017.

xxxviii + 360 p. ; (sid.inpe.br/mtc-m21b/2017/02.22.14.03-TDI)

Dissertação (Mestrado em Engenharia e Tecnologia Espaciais/Engenharia e Gerenciamento de Sistemas Espaciais) – Instituto Nacional de Pesquisas Espaciais, São José dos Campos, 2017.

Orientador : Dr. Geilson Loureiro.

1. Engenharia de sistemas. 2. Engenharia simultânea. 3. Montagem integração e testes.AIT. 4. Equipamento de suporte em solo.GSE. 5. Satélite. I.Título.

CDU 629.78

Esta obra foi licenciada sob uma Licença Creative Commons Atribuição-NãoComercial 3.0 Não Adaptada.

This work is licensed under a Creative Commons Attribution-NonCommercial 3.0 Unported License.

“δῶςµοιπᾶστῶκαὶτὰνγᾶνκινάσω”

“Dê-me um ponto de apoio, e eu movo o mundo”.

Arquimedes de Siracuse

A Gianna Gonçalves Venticinque

vii

viii

AGRADECIMENTOS

Devo agradecer a todos por terem tornado possível a realização deste trabalho.

Ao Dr. Geilson Loureiro pela orientação e apoio.

Ao INPE por ter me dado oportunidade de participar de vários programas espaciais e tornar possível este trabalho.

Ao LIT por apoiar, permitir e viabilizar a realização deste trabalho.

Aos colegas do INPE que contribuem para o desenvolvimento tecnológico do Brasil e com os quais aprendi muito.

Aos colegas do LIT, que admiro e respeito, que apoiaram, e contribuíram para o desenvolvimento deste trabalho.

RESUMO

Este trabalho objetiva investigar o desenvolvimento de uma classe de produtos de apoio (“enabling products”), conhecidos como Equipamento de Suporte em Solo (GSE) (“Ground Support Equipment”), necessários para suporte e execução das atividades de integração e testes (AIT) de um produto espacial. Normas e literatura proveem material abundante para desenvolvimento de produtos de interesse e tratam o desenvolvimento de produtos de apoio apenas aplicando a recursividade do processo de engenharia de sistemas. A consequência dessa abordagem é a dificuldade de capturar os requisitos do produto de apoio no momento da decomposição do produto de interesse, já que o produto de apoio possui o design acoplado ao design do produto de interesse. Como forma de superar esta dificuldade, este trabalho propõe um guia de desenvolvimento de GSE, com o objetivo principal de servir de referência ao advertir e orientar os desenvolvedores durante as fases iniciais do desenvolvimento do produto espacial, do processo de AIT e do GSE, para as dificuldades e armadilhas encontradas na abordagem tradicional de desenvolvimento de GSE. O guia proposto apresenta uma síntese das diretivas encontradas nas normas e manuais aplicáveis sobre o desenvolvimento de produtos de apoio e propõe um processo que integre essas diretivas, correlacionando de forma simultânea e colaborativa o desenvolvimento do GSE ao desenvolvimento do produto espacial e seu processo de AIT.

Palavras-chave: Produto de apoio. Produto de Interesse. Engenharia de Sistemas. Engenharia Simultânea. Montagem Integração e Testes. AIT. Equipamento de Suporte em Solo. GSE. Análise Estruturada. Satélite. Produto Espacial. EGSE. MGSE.

xii

SYSTEM ENGINEERING APPLIED FOR DEVELOPMENT OF GROUND

SUPPORT EQUIPMENT – GSE

ABSTRACT

This work addresses the development of a class of enabling products, known as Ground Support Equipment (GSE), necessary to support a space product during its integration and testing activities (AIT). Standards and literature provide abundant material for the development of products-of-interest and address the development of enabling products only by applying the recursiveness of the systems engineering process. The consequence of this approach leads to difficulty in capturing the requirements of the enabling products at the moment of decomposition of the product-of-interest, since the enabling product has the design coupled to the design solution of the product-of-interest. To overcome this difficulty, this work proposes a GSE development guide, with the main objective of being a reference for the development of GSE by advising and guiding the developers during the initial stages of development of the space product, its AIT process and the GSE, for the difficulties and pitfalls found in the traditional approach. The proposed guide presents a synthesis of the directives found in the applicable standards and manuals on the development of enabling products and proposes a process that integrates these directives, simultaneously and collaboratively correlating the development of the GSE to the development of the space product and its AIT process.

Keywords: Enabling product. Product-of-interest. Systems Engineering. Concurrent Engineering. Assembly Integration and Testing. AIT. Ground Support Equipment. GSE. Structured Analysis. Satellite. Space product. EGSE. MGSE.

xiii

xiv

LISTA DE FIGURAS

Pág.

Figura 1.1 – Os processos do ciclo de vida como elementos do sistema………………………………………………2

Figura 1.2 – Distribuição das Não-Conformidades em AIT.………………………………………………………………..5

Figura 1.3 – Probabilidade de Horas Gastas por Não-Conformidade Baseado em Dados de Entrevista…..6

Figura 1.4 – Histograma do Tempo Gasto por Não-Conformidade Por Satélite…………………………………….6

Figura 2.1 – As Três Atividades Principais da Gestão de Engenharia de Sistema …………………………………12

Figura 2.2 – Desenvolvimento Faseado …………………………………………………………………………………………15

Figura 2.3 – Processo de Engenharia de Sistemas…………………………………………………………………………..16

Figura 2.4 – Exemplo de Sistemas Abertos …………………………………………………………………………………….37

Figura 2.5 – Engenharia de Sistemas no contexto do Gerenciamento de Projeto ………………………………..39

Figura 2.6 – Motor de Engenharia de Sistemas (Motor SE)………………………………………………………………40

Figura 2.7 – Ciclo de Vida do Projeto…………………………………………………………………………………………….41

Figura 2.8 – Hierarquia dos Elementos de um Sistema ……………………………………………………………………47

Figura 2.9 – Os Tijolos Básicos (“Building Blocks”) do Sistema …………………………………………………………48

Figura 2.10 – Ciclo de Vida Típico de um Sistema Durante Desenvolvimento e Operação…………………….51

Figura 2.11 – Engenharia Simultânea dos Processos do Ciclo de Vida ……………………………………………….56

Figura 2.12 – Processo de Engenharia de sistemas – SEP…………………………………………………………………57

Figura 2.13 – Histórico simplificado das normas ISO de Engenharia de Software e de Sistema ..…………..63

Figura 2.14 – A Estrutura do Sistema de Interesse ………………………………………………………………………….64

Figura 2.15 – Comparação do escopo das normas ISO/IEC15288:2008 e IEEE-Std-1220:2005 ao longo do

ciclo de vida………………………………………………………………………………………………………………………………65

Figura 2.16 – Papeis nos acordos organizacionais…………………………………………………………………………..67

Figura 2.17 – Sistema de padronização ECSS Fonte: ECSS (2016).…………………………………………………….80

Figura 2.18 – Funções de Engenharia de sistemas e seus perímetros ………………………………………………..81

Figura 2.19 – Ciclo de Vida de um Projeto de acordo com a ESA/ECSS……………………………………………….82

Figura 2.20 – Ciclo de Vida das Revisões Segundo a ECSS ………………………………………………………………..83

Figura 2.21 – Modelo Sequencial de desenvolvimento…………………………………………………………………….90

Figura 2.22 – Lado Esquerdo e Direito do Modelo em Vê..……………………………………………………………….91

Figura 2.23 – Modelo Espiral de desenvolvimento ………………………………………………………………………….92

Figura 2.24 – Duração do Desenvolvimento Enfoque Tradicional x Engenharia Simultânea ……………….101

Figura 2.25 – Processo de Implementação Gradual de Engenharia Simultânea ………………………………..104

Figura 2.26 – Desdobramento Funcional de Qualidade “House of Quality” ……………………………………..108

Figura 2.27 – As Três Dimensões do Framework de Visão Total……………………………………………………..111

Figura 2.28 – Comparação Entre o Escopo do Sistema da Norma EIA-632 (ANSI,1997) em Relação ao

Framework de Visão Total. ……………………………………………………………………………………………………….112

Figura 2.29 – As três dimensões da Evolução do Framework de Visão Total …………………………………….113

Figura 2.30 – A Evolução do Método Estruturado de Engenharia Simultânea .………………………………..113

Figura 2.31 – Modelo de DFD adaptado para Análise de Requisitos de Produto……………………………….115

Figura 2.32 – Modelo de IDEF0 adaptado para Análise de Requisitos de Processo……………………………116

Figura 2.33 – Exemplo de Diagrama Use Case adaptado para Análise de Requisitos de Organização …117

Figura 2.34 – Requisitos e Atributos de um Sistema Fonte: Adaptado de Loureiro (1999).………………..119

Figura 3.1 – Sistema de Interesse, seu Ambiente Operacional e os Sistemas de Apoio……………………….124

Figura 3.2 – Realização de Sistema de Apoio………………………………………………………………………………..125

Figura 3.3 – Processo de Definição da Solução de Design da NASA …………………………………………………128

Figura 3.4 – Hierarquia do Sistema:……………………………………………………………………………………………130

Figura 3.5 – Correlação do Ciclo de Vida de um Sistema, um subsistema e seu EGSE com destaque na fase

E ……………………………………………………………………………………………………………………………………………131

Figura 4.1 – Visão de raio-X do satélite CBERS 3. .…………………………………………………………………………136

Figura 4.2 – Árvore de documentos de sistema do programa CBERS 3&4 .……………………………………….138

Figura 4.3 – Plano de Testes dos Modelos do CBERS 3/4.………………………………………………………………141

Figura 4.4 – Estrutura da Árvore de Produto – PBS do CBERS 3 & 4.……………………………………………….146

Figura 4.5 – Concepção dos Estados de Montagem do Satélite CBERS ……………………………………………154

Figura 4.6 – Sequência do AIT do CBERS..…………………………………………………………………………………….155

Figura 4.7 – Diagrama em blocos do EGSE CBERS 3&4………………………………………………………………….159

Figura 4.8 – Conceito de Operação do EGSE durante AIT……………………………………………………………….159

Figura 4.9 Família de plataformas desenvolvidas pela Thales, com destaque ao Spacebus C4.…………..165

Figura 4.10 Vista da SGDC na Configuração Normal de vôo...………………………………………………………..167

Figura 4.11 – Ciclo de Desenvolvimento de Satélites de Comunicações ……………………………………………168

Figura 4.12 – Estrutura de Hierarquia de Produto (PBS) do Spacebus 4000 C com destaque para os GSEs

……………………………………………………………………………………………………………………………………………..169

Figura 4.13 – Estrutura da Divisão do Trabalho (WBS) do SGDC.…………………………………………………….170

Figura 4.14 – Diagrama das atividades do Plateau no Ciclo de Vida do Satélite com destaque para as

restrições dos meios de AIT.………………………………………………………………………………………………………171

Figura 4.15 – O processos de AIT versus Cronograma do projeto ..………………………………………………….177

Figura 4.16 – Sequência Inversa de AIT para Satélites de Telecomunicações……………………………………183

Figura 4.17 – Especificação de vibração para COTE durante lançamento………………………………………..184

Figura 4.18 – Interface umbilical com o satélite acoplado ao lançador e EGSE …………………………………185

xvi

Figura 4.19 – Configuração de controle remoto do satélite durante campanha de lançamento ..………186

Figura 4.20 – Configuração típica da rede de dados na base de lançamentos…………………………………..187

Figura 4.21 – Concepção Artística do Satélite AMAZONIA–1 ………………………………………………………….191

Figura 4.22 – Segmento Espacial do WBS do AMAZONIA-1……………………………………………………………192

Figura 4.23 – Diagrama em blocos do EGSE Amazonia-1 com destaque ao SCS SCOE……………………….193

Figura 4.24 – Diagrama de contexto EGSE Amazônia 1 durante AIT.………………………………………………194

Figura 4.25 – Diagrama de contexto do SCS SCOE do Amazônia 1 durante AIT ………………………………..197

Figura 4.26 – Diagrama de Contexto do EGSE Amazônia 1 Durante Lançamento……………………………..198

Figura 5.1 – IDEF0 do Processo de AIT ………………………………………………………………………………………..202

Figura 5.2 – Relação entre Escopo de Interesse e Controle do Projeto…………………………………………….203

Figura 5.3 – Estrutura hierárquica do Sistema e a Definição de seus Processos do Ciclo de Vida ..……..206

Figura 5.4 – Exemplo de Diagrama IDEF5 do Módulo de Carga Útil de um Satélite………………………….235

Figura 5.5 – Interfaces Organizacionais para desenvolvimento de produto espacial, AIT e GSE………….238

Figura 5.6 – Processo de Desenvolvimento Integrado de GSE.………………………………………………………..245

Figura 5.7 – Processo de Análise de Sistema aplicado ao Produto Espacial (S).…………………………………246

Figura 5.8 – Exemplos de SBS de um Satélite……………………………………………………………………………….249

Figura 5.9 – Processo Análise de Verificação de Sistema (S5) .………………………………………………………..250

Figura 5.10 – Processo Análise de Integração de Sistema (S6)………………………………………………………..253

Figura 5.11 – Processo de Análise de AIT (A) .………………………………………………………………………………256

Figura 5.12 – Processo Análise de e GSE de Sistema (G)…………………………………………………………………259

Figura 5.13 – Loops Externos do Processo de Desenvolvimento Integrado do GSE ……………………………264

Figura 5.14 – Padronização de GSE entre Projetos……………………………………………………………………….268

Figura 5.15 – Processo Análise de Subsistema (SS)………………………………………………………………………..269

Figura 5.16 – Processo Análise de AIT de Subsistema (AS) ……………………………………………………………..270

Figura 5.17 – Processo Análise de GSE de Subsistema (GS).……………………………………………………………271

Figura 6.1 – Processos do PDIG aplicados no desenvolvimento do UMB SCOE ..……………………………….275

Figura 6.2 – Ciclo de Vida do Satélite………………………………………………………………………………………….276

Figura 6.3 – Árvore de Produtos dos Satélite Amazonia–1……………………………………………………………..277

Figura 6.4 – Decomposição dos Cenários de AIT e lançamento do Satélite……………………………………..279

Figura 6.5 – Cenários Relevantes para EGSE no ciclo de vida do satélite…………………………………………280

Figura 6.6 – Diagrama de Contexto do EGSE no Cenários S203:Integração e Testes Iniciais do Módulo de

Serviço – SM…………………………………………………………………………………………………………………………….281

Figura 6.7 – Diagrama de Contexto do EGSE no Cenários S205: Integração e Testes Iniciais do Satélite 282

Figura 6.8 – Diagrama de Contexto do EGSE nos Cenários Relevantes de AIT: Caso Geral .………………..283

Figura 6.9 – Diagrama de Contexto do EGSE no Cenário S307: Satélite na Torre de Lançamento ……….284

xvii

Figura 6.10 – Conceito de Operações do UMB SCOE para Enlace de Telemetria e Telecomando ..………285

Figura 6.11 – Ciclo de vida do UMB SCOE.……………………………………………………………………………………286

Figura 6.12 – Cenários Relevantes do Ciclo de Vida do UMB SCOE ………………………………………………….286

Figura 6.13 – Stakeholders de Produto e Processo para Desenvolvimento UMB ..…………………………….289

Figura 6.14 – Stakeholders de Produto e Processo para Fabricação/Aquisição de componentes do UMB

SCOE………………………………………………………………………………………………………………………………………289

Figura 6.15 – Stakeholders de Produto e Processo para Montagem e integração do UMB SCOE.………..290

Figura 6.16 – Stakeholders de Produto e Processo para Verificação do UMB SCOE……………………………290

Figura 6.17 – Stakeholders de Produto e Processo para Transição do UMB SCOE.…………………………….290

Figura 6.18 – Stakeholders de Produto e Processo para Operação durante Validação do UMB SCOE..…291

Figura 6.19 – Stakeholders de Produto e Processo para Operação em AIT do UMB SCOE…………………..291

Figura 6.20 – Stakeholders de Produto e Processo para Operação em Lançamento do UMB SCOE ……..291

Figura 6.21 – Stakeholders de Produto e Processo para Operação durante Aferição de Calibração do UMB

SCOE………………………………………………………………………………………………………………………………………292

Figura 6.22 – Stakeholders de Produto e Processo para Operação – Manutenção do UMB SCOE .……….292

Figura 6.23 – Stakeholders de Produto e Processo para Transporte do UMB SCOE……………………………292

Figura 6.24 – Stakeholders de Produto e Processo para Descomissionamento do UMB SCOE .……………293

Figura 6.25 – Stakeholders de Organização do UMB SCOE …………………………………………………………….293

Figura 6.26 – Modelagem de Ambiente do Cenário U11 e suas Circunstâncias ………………………………..306

Figura 6.27 – Modelagem de Ambiente do Cenário U13 e suas Circunstâncias ………………………………..306

Figura 6.28 – Modelagem de Ambiente do Cenário U31 e suas Circunstâncias ………………………………..307

Figura 6.29 – Modelagem de Ambiente do Cenário U32 e suas Circunstâncias ………………………………..307

Figura 6.30 – Modelagem de Ambiente do Cenário U33 e suas Circunstâncias ………………………………..307

Figura 6.31 – Análise de Escopo das Funções F1, F2, F3 e F4 do UMB SCOE …………………………………….312

Figura 6.32 – Análise de Escopo das Funções F5,F6,F7 e F8 do UMB SCOE ………………………………………313

Figura 6.33 – Análise de Escopo das Funções F9, F10, F11, F12 e F13 do UMB SCOE..……………………….313 Figura 6.34 – Gráfico N2 – Identificação das Interfaces funcionais…………………………………………………..314

Figura 6.35 – Diagrama de Transição de Estados das Funções F2, F3 e F4 .………………………………………316

Figura 6.36 – Diagramas de transição de Estados da função F6 ……………………………………………………..317

Figura 6.37 – Diagramas de Transição de Estados das Funções F7, F8 e F9..…………………………………….317

Figura 6.38 – Diagramas de Transição de Estados das Funções F10 e F11 .………………………………………318

Figura 6.39 – Arquitetura Funcional: Monitoração……………………………………………………………………….319

Figura 6.40 – Arquitetura Funcional: Comandar Satélite……………………………………………………………….320

Figura 7.1 – Gráfico N2 Parcial com Destaque à Funções F13,14 e 15 do UMB SCOE.……………………….334

xviii

Figura A.1 – Processo de Análise Estruturada de Sistema………………………………………………………………355

Figura A.2 – Processo de Análise de Missão – P0 ………………………………………………………………………….355

Figura A.3 – Processo Análise de Stakeholder – P1………………………………………………………………………..356

Figura A.4 – Processo Análise de Requisitos – P2 ………………………………………………………………………….357

Figura A.5 – Processo de Análise Funcional – P3 …………………………………………………………………………..358

Figura A.6 – Processo de Análise Implementação – P4..…………………………………………………………………359

xix

LISTA DE TABELAS

Pág.

Tabela 2.1 – Ciclo de vida do Projeto de acordo com a nomenclatura da NASA ………………………………….43

Tabela 2.2 – Documentos Entregáveis de Engenharia de Sistema…………………………………………………….85

Tabela 2.3 – Comparação entre os modelos de desenvolvimento……………………………………………………..93

Tabela 2.4 – Proposta de abordagem e notação para modelagem…………………………………………………114

Tabela 4.1 – Tabela com o Cronograma e a Quantidade de ESEs fornecidos para o EPSS .…………………147

Tabela 4.2 – Lista de Requisitos para EPSS no Documento de Requisitos do Satélite..……………………….150

Tabela 4.3 – Lista de Aplicabilidade dos Testes Funcionais e de Performance do subsystema EPSS …….151

Tabela 4.4 – Fases de AIT versus Estado do Satélite CBERS ……………………………………………………………153

Tabela 4.5 – Componentes do EGSE .…………………………………………………………………………………………..160

Tabela 4.6– Etapas do Processo de Plateau da Thales para Desenvolvimento de Satélites de

Telecomunicações Baseados na Plataforma Spacebus………………………………………………………………….172

Tabela 4.7 – Características da PMM .………………………………………………………………………………………..190

Tabela 4.8 – Descrição Simplificada dos Elemento do EGSE do Satélite Amazonia-1…………………………194

Tabela 5.1 – Produtos de Apoio de Design de Hardware……………………………………………………………….232

Tabela 5.2 – Produtos de Apoio de Design de Software ..………………………………………………………………233

Tabela 5.3 – Produtos de Apoio de Design de Processo…………………………………………………………………234

Tabela 6.1 – Dicionário de Stakeholders do UMB SCOE..………………………………………………………………..288

Tabela 6.2 – Visão Geral dos Stakeholders e suas Preocupações para Produto, Processo e Organização

em Todos os Cenários do Ciclo de Vida……………………………………………………………………………………….295

Tabela 6.3 – Matriz de Requisitos de Produto derivados das preocupação dos Stakeholders……………..297

Tabela 6.4 – Matriz de Requisitos de Stakeholders para Processos…………………………………………………299

Tabela 6.5 – Matriz de Requisitos de Organização……………………………………………………………………….300

Tabela 6.6 – Matriz QFD das Medidas de Efetividade MoE e Interesse dos Stakeholders para Produto..301

Tabela 6.7 – Classificação das Medidas de Efetividade – MoE de Produto ……………………………………….302

Tabela 6.8 – MOEs e seus Pressupostos ………………………………………………………………………………………303

Tabela 6.9 – Lista dos Pressupostos……………………………………………………………………………………………304

Tabela 6.10 – Cenários Relevantes do UMB SCOE e suas Circunstâncias ………………………………………….305

Tabela 6.11 – Eventos e Estímulos e as Repostas do UMB SCOE……………………………………………………..308

Tabela 6.12 – Lista de Fluxos Identificados em Cada Circunstância …………………………………………………309

Tabela 6.13 – Eventos e MoEs e Funções……………………………………………………………………………………..310

Tabela 6.14 – Estado e modos do UMB SCOE.……………………………………………………………………………..315

xxi

Tabela 7.1 – Matriz de Correspondência Funcional do SCS SCOE com o UMB SCOE .…………………………327

Tabela 7.2 Stakeholders e suas Preocupações Relacionados com a Medida de Efetividade MOE_007...329

Tabela 7.3 – Medida de Efetividade MOE_007 Relacionada como a Função Alimentar Satélite (F9)..….329

Tabela 7.4 – MOE_006 – Medida de Efetividade relacionada como a função F11 – Auxiliar Calibração..331

Tabela 7.5 – Medida de Efetividade relacionada como a função F13 – Rotear..…………………………………333

xxii

LISTA DE SIGLAS E ABREVIATURAS

ACD Diagrama De Atividades (Activity Diagram )

ACDH Subsistema de Controle e Gerenciamento de Dados (Attitude Control and Data Handling)

AIAA American Institute of Aeronautics and Astronautics AID Diagrama De Interconexão De Arquitetura

(Architecture Interconnect Diagram )

AIT Montagem Integração e Testes (Assembly Integration and Test) AITP Plano de AIT (assembly, integration and test plan)

AIV Montagem Integração e Verificação (Assembly Integration and Verification)

AIVP Plano de AIV (Assembly, Integration and Verification Plan) ANSI American National Standards Institute

AOCS Subsistema de Controle de Atitude e Órbita (Attitude and Orbit Control Subsystem)

API Interface de Programação de Aplicativos (Application Programming Interface)

ARPT Relatório de Análise (Analysis Report)

ATB Banco de Testes da Aviônica (Avionics Test Bench) AWDT Subsistema de Transmissão de Dados do AWFI

(AWFI Data Transmitter)

AWFI Imagiador de Visada Larga Avançado (Advanced Wide Field Imager)

BAF Instalações de Montagem Final (Final Assembly Building) BD Diagrama de Comportamento (Behaviour Diagram )

BOB Caixa de Acesso a Conectores (Break-Out-Box) BOE Basis of Estimate

BTC Condicionador de Bateria (PSS SCOE) (Battery Conditioner) BTS Simulador de Bateria (PSS SCOE) (Battery Simulator)

CAD Computer-Aided Design CAD Computer-Aided Design CAE Computer-Aided Engineering CAE Computer-Aided-Engineering

CAIV Cost as an Independent Variable CAM Computer-aided Manufacturing CAPP Computer-Aided Process Planning

CASE Computer-Aided-Systems Engineering

CCSDS Consultative Committee for Space Data Systems CD Diagrama de Classe (Class Diagram )

CDF Concurrent Design Facility

CDS Folha de Descrição de Conceito (Concept Description Sheet)

CE Engenharia Silmultânea (Concurrent Engineering) CMMI Modelo de Maturidade em Capacitação – Integração

(Capability Maturity Model – Integration )

COD Diagrama de Colaboração (Collaboration Diagram ) CoF Contrução de Infraestrutura (Construction of Facilities)

xxiii

COTE Equipamento de Operação e Testes (do Satélite) (Check-Out Test Equipment)

COTS Equipamento Cormercial de Prateleira (Commercial-Off-The-Shelf)

CPD Diagrama de Componentes (Component Diagram )

CPD Desenvolvimento Digital de Produto (Digital Product Development) DDF Dossier de Definição de Projeto (Design Definition File)

DDR Subsistema Gravador Digital de Dados (Digital Data Recorder) DETER Detecção de Desmatamento em Tempo Real

DFA Design para Montagem (Design For Assembly) DFD Diagrama de Fluxo de Dados (Data Flow Diagram ) DFM Design para Manufatura (Design For Manufacture)

DJF Dossier de Justificação de Projeto (Design Justification File) DOE Design Experimental (Design of Experiments)

DPD Diagrama de Desdobramento (Deployment Diagram )

DSD Diagrama de Estrutura De Dados (Data Structure Diagram ) DSL Linguagens Específicas (Domain-Specific Languages)

DSS Simulador Dinâmico do Satélite (Dinamic Satellite Simullator) DVM Matriz de Verificação de Projeto (Design Verification Matrix) ECSS European Cooperation on Space Standardization

Effbd Diagrama De Bloco De Fluxo Funtional (Enhanced Functional Flow Block Diagram)

EGSE Equipamento Elétrico de Suporte em Solo (Electrical Ground Support Equipment)

EIDP Pacote de Dados de Produto Final (End Item Data Package)

EMC Compatibilidade Eletromagnética (Electromagnetic Compatibility)

EMI Interferência Eletromagnética (Electromagnetic Interference)

ERD Diagrama Entidade Relacionamento (Entity Relationship Diagram ) ESA European Space Agency

ESI Envolvimento Antecipado de Fornecedor (Early Supplier Involviment)

FBD Diagrama de Blocos Funcional (Function Block Diagram ) FFT Teste Funcional Completo (Full Functional Test)

FS&GS Sistema de Voo e Suporte em Solo (Flight Systems and Ground Support)

FTC Ficha Técnica de Concepção de Design (Fiche Technique de Conception)

FTO Ficha Técnica das Ferramentas e Interfaces (Fiche Technique d’Outillage)

GFE Equipamento Mobiliado do Governo (Government Furnished Equipment)

GPS Sistema de Posicionamento Global (Global Positioning System) GSE Equipamento de Suporte em Solo (Ground Support Equipment) HPF Instalações de Processamento Periculoso

(Hazardous Processing Facility)

ICS Documento de Controle de Interface (Interface Control Document)

IDEF Integration DEFinition for Function Modeling

xxiv

IEC International Electrotechnical Commission INPE Instituto Nacional de Pesquisas Espaciais IPD Desenvolvimento Integrado de Produto

(Integrated Product Development)

IPPD Desenvolvimento Integrado de Produto e Processo (Integrated Product and Process Development)

IPT Equipe Integrada de Produto (Integrated Product Team) IRPT Relatóirio de Inspeção (Inspection Report)

ISO International Organization for Standardization

IST Sistema de Teste Integrado (Integrated System Test) KDP Pontos Chaves de Decisão (Key Decision Points)

KPP Parâmetros Chaves de Desempenho (Key Performance Parameters) LAN Rede Local de Computadores (Local Area Network)

LCC Custo do Ciclo de Vida (Life Cycle Cost) LIT Laboratório de Integração e Testes

LRR Revisão de Prontidão de Lançamento (Launch Readness Review) LVDS Low Voltage Differential Signaling

MCR Mission Close-out Review

MDD Documento de Descrição de Missão (Mission Description Document) MDR Revisão de Definição de Missão (Mission Definition Review)

MGSE Equipamento Mecânico de Suporte em Solo (Mechnical Ground Support Equipment)

MMP Plataforma Multi-Missão (Multi-Mission Platform)

MNS Declaração de Necessidades da Missão (Mission Statement) MOE Medida da Eficácia (Measure of Effectiveness (MOE))

MOP Medida de Desempenho (Measure of Performance (MOP)) MOS Medida da Adequação (Measure of Suitability (MOS))

NDI Item Não Desenvolvidos (Non-Developmental Item) NRZ-L (Non Return to Zero-Low)

OBDH Subsistema de Gerenciamento de Dados a Bordo (On Board Data Handling)

OBS Estrutura da Divisão Organizacional (Organization Breakdown Structure)

OCOE Equipamento Central de Teste (do EGSE) (Overal Check Out Equipment)

ORD Documento de Requisitos Operacionais (Operational Requirements Document)

ORR Operational Readness Review

PAD Diagrama De Arquitetura Física ( Physical Architecture Diagram ) PBS Estrutura da Divisão de Produto (Product Breakdown Structure) PCDU Unidade de Condicionamento e Distribuição de Energia

(Power Conditioning and Distribution Unit)

PCM Modulação por Código de Pulsos (Pulse Code Modulation) PD Diagrama De Pacote (Package Diagram )

PDRR Definição do Programa e Redução de Risco (Program Definition and Risk Reduction)

PFD Diagrama De Fluxo De Processo ( Process Flow Diagram ) PM Módulo de Carga Útil (Payload Module)

PMM Plataforma Multi-Missão

xxv

PMO Escritório de Gerenciamento do Programa (Program Management Office)

PPF Instalações de Preparação da Carga-Útil (Satélite) (Payload Preparation Facility)

PROP Subsistema Propulsão (Propulsion Subsistem)

PRR Revião Preliminar de Requisitos (Preliminary Requirements Review) PSS Subsistema de Fornecimento de Energia (Elétrica)

(Power Supply Subsystem)

QDF Desdobramento (ou Matriz) Funcional da Qualidade (Quality Function Deployment)

QR Revisão de Qualificação (Qualification Review) RAM Matriz de Atribuição de Responsabilidades

(Responsability Assignment Matrix )

RAS Folhas de Alocação de Requisitos (Requirements Allocation Sheets) REX Retorno de Experiência

RFT Teste Funcional Reduzido (Reduced Functional Test)

ROM Ordem Aproximada de Magnitude (Rough Order of Magnitude) S/C Satélite/Artefato espacial (Spacecraft)

S/S Subsistema (Subsystem)

SAD Diagrama de Arquitetura de Software ( Software Architecture Diagram) SADA Solar Array Drive Assembly

SAG Gerador Solar (Solar Array Generator)

SAS Simulador de Painel Solar (Solar Array Simulator)

SBD Diagrama de Blocos Esquemático (Schematic Block Diagram ) SBS Estrutura da Divisão de Sistema (System Breakdown Struture) SCD Diagrama de Estado (State Chart Diagram )

SCOE Equipamento Específico de Teste (do EGSE) (Specific Check Out Equipment)

SCS Subsistema de Circuito de Sistema (System Circuit Subsystem) SEP Plano de Engenharia de Sistema (System Egineering Plan)

SEP Processo de Engenharia de Sistemas (System Egineering Process) SFT Teste Funcional de Sistema (System Functional Test)

SIS Simulador de Interface de Satélite (Satellite Interface Simulator) SM Módulo de Serviço (Service Module)

SORCER Service-Oriented Computing Environment SOW Declaração de Trabalho (Statement Of Work ) SQD Diagrama De Sequência (Sequence Diagram )

SRR Revisão de Requisitos de Sistema (System Requirements Review) SSO Órbita Heliossíncrona (Sun-Synchronous Orbit)

STC Diagrama De Estrutura Gráfica (Structure Chart )

STD Diagrama De Transição De Estados (State Transition Diagram ) TBU Unidade Base de Tempo (Time Base Unit)

TC Telecomando (Telecommand)

TCS Subsistema de Controle Térmico (Thermal Control Subsystem)

TEMP Plano Diretor de Teste e Avaliação (Test and Evaluation Master Plan) TM Telemetria (Telemetry)

TP Plano Tecnológico (Technology Plan)

xxvi

TPM

TPRO TQM

TRL

TRTP TS TSPE

TTC/TT&C

UCD UMB VCD VP VR VRPT WBS WFI

Medida de Desempenho Técnico (Techinical Performance Measurement) Procedimento de Teste (Test Procedure) Gerenciamento de Qualidade Total (Total Quality Management)

Maturidade do Desenvolvimento Tecnológico (Technology Readiness Level)

Relatório de Teste (Test Report)

Requisitos Técnicos (Techical Specification) Especificação de Teste (Test Specification)

Telemetria, Telecomando e Rastreio (Telemetry, Tracking, and Command)

Diagrama De Caso De Uso (Use Case Diagram ) Umbilical (Umbilical)

Documento de Controle de Verificação (Verification Control Document) Plano de Verificação (Verification Plan)

Redução da Variabilidade (Variability Reduction) Relatório de Verificação (Verification report)

Estrutura da Divisão de Trabalho (Work Breakdown Structure ) Imagiador de Visada Larga (Wide Field Imager)

xxvii

xxviii

SUMÁRIO

Pág.

1 INTRODUÇÃO ……………………………………………………………………………………………………1

1.1 MOTIVAÇÃO ………………………………………………………………………………………………………. 2

1.1.1 Design Acoplado do GSE……………………………………………………………………………… 2

1.1.2 Modelo de Desenvolvimento para GSE………………………………………………………….. 3

1.1.3 Implementação do GSE……………………………………………………………………………….. 4

1.1.4 Discrepâncias de GSE………………………………………………………………………………….. 4

1.1.5 Falta de Padronização ………………………………………………………………………………… 7

1.1.6 Falta de Dossiê de Definição de AIT………………………………………………………………. 8

1.2 OBJETIVOS ESPECÍFICOS …………………………………………………………………………………………. 8

1.3 METODOLOGIA……………………………………………………………………………………………………. 8

1.4 ESTRUTURA DO DOCUMENTO…………………………………………………………………………………… 9

2 FUNDAMENTAÇÃO TEÓRICA………………………………………………………………………………11

2.1 ENGENHARIA DE SISTEMAS SEGUNDO O DOD……………………………………………………………… 11

2.1.1 Introdução a Gerenciamento de Engenharia de Sistema ……………………………….. 11

2.1.2 Integração do Ciclo de Vida……………………………………………………………………….. 12

2.1.3 Funções do Ciclo de Vida …………………………………………………………………………… 13

2.1.4 Desenvolvimento Faseado…………………………………………………………………………. 14

2.1.4.1 Considerações de desenvolvimento nos níveis hierárquico de sistema…………………………………15

2.1.5 O Processo de Engenharia de Sistema…………………………………………………………. 15

2.1.5.1 Processo de Análise de Requisitos……………………………………………………………………………………16

2.1.5.1.1

2.1.5.1.2

2.1.5.1.3

O papel das equipes integradas ……………………………………………………………………………….17

Questões Análise de Requisitos ……………………………………………………………………………….18

Detalhando o Processo de Análise de Requisitos………………………………………………………..18

2.1.5.2

2.1.5.3

2.1.5.4

Processo de Análise Funcional e Alocação ………………………………………………………………………..27

Processo de Síntese de Design ………………………………………………………………………………………..30

Processo de Análise de Sistemas e Controle ……………………………………………………………………..32

2.1.6 Estrutura da Divisão de Trabalho (WBS)………………………………………………………. 33

2.1.6.1

2.1.6.2

Objetivos do WBS………………………………………………………………………………………………………….34

Desenvolvendo o WBS……………………………………………………………………………………………………34

2.1.7 Sistemas Abertos ……………………………………………………………………………………… 36

xxix

2.2 ENGENHARIA DE SISTEMAS SEGUNDO O NASA ……………………………………………………………. 37

2.2.1 O Processo de Engenharia de Sistemas ……………………………………………………….. 38

2.2.2 O Ciclo de Vida…………………………………………………………………………………………. 40

2.2.3 Discussão sobre Engenharia Simultânea ……………………………………………………… 44

2.3 ENGENHARIA DE SISTEMAS SEGUNDO A NORMA IEEE-STD-1220:2005……………………………… 45

2.3.1 Introdução ………………………………………………………………………………………………. 45

2.3.2 Hierarquia de Sistema ………………………………………………………………………………. 46

2.3.3 Building Blocks…………………………………………………………………………………………. 47

2.3.4 Processos do Ciclo de Vida…………………………………………………………………………. 48

2.3.5 Requisitos Gerais ……………………………………………………………………………………… 49

2.3.6 Aplicando o Processo de Engenharia de Sistemas no Ciclo de Vida………………….. 51

2.3.6.1

2.3.6.2

2.3.6.3

2.3.6.4

2.3.6.5

2.3.6.6

Fase de Definição do Sistema:…………………………………………………………………………………………51

Fase de Design Preliminar ………………………………………………………………………………………………52

Fase de Design Detalhado ………………………………………………………………………………………………53

Fase de Fabricação, Montagem, Integração e Teste …………………………………………………………..54

Fase de Produção e Suporte……………………………………………………………………………………………54

Engenharia Simultânea e os Processos do Ciclo de Vida……………………………………………………..54

2.3.7 Processo de Engenharia de Sistemas…………………………………………………………… 57

2.3.7.1

2.3.7.2

2.3.7.3

2.3.7.4

2.3.7.5

2.3.7.6

2.3.7.7

2.3.7.8

Análise de Requisitos……………………………………………………………………………………………………..57

Validação de Requisitos………………………………………………………………………………………………….58

Análise Funcional…………………………………………………………………………………………………………..59

Verificação Funcional……………………………………………………………………………………………………..59

Síntese …………………………………………………………………………………………………………………………60

Verificação de Projeto…………………………………………………………………………………………………….60

Análise de Sistemas ……………………………………………………………………………………………………….61

Controle……………………………………………………………………………………………………………………….62

2.4 ENGENHARIA DE SISTEMAS SEGUNDO A NORMA ISO/IEC15288:2008………………………………. 63

2.4.1 Histórico………………………………………………………………………………………………….. 63

2.4.2 Estrutura de Sistema…………………………………………………………………………………. 63

2.4.3 Sistema de Apoio ……………………………………………………………………………………… 64

2.4.4 Ciclo de Vida do Sistema……………………………………………………………………………. 65

2.4.5 Processos do Ciclo de Vida…………………………………………………………………………. 66

2.4.5.1 Processos de Acordo………………………………………………………………………………………………………66

2.4.5.1.1

2.4.5.1.2

Processo de Aquisição…………………………………………………………………………………………….67

Processo de Fornecimento………………………………………………………………………………………67

xxx

2.4.5.2 Processos Organizacionais de Apoio ao Projeto…………………………………………………………………67

2.4.5.2.1

2.4.5.2.2

2.4.5.2.3

2.4.5.2.4

2.4.5.2.5

Processo de Gerenciamento do Modelo do Ciclo de Vida ……………………………………………68

Processo de Gerenciamento de Infraestrutura…………………………………………………………..68

Processo de Gerenciamento de Portfólio de Projetos …………………………………………………68

Processo de Gerenciamento de Recursos Humanos……………………………………………………69

Processo de Gerenciamento de Qualidade………………………………………………………………..69

2.4.5.3 Processos de Projeto ……………………………………………………………………………………………………..69

2.4.5.3.1

2.4.5.3.2

2.4.5.3.3

2.4.5.3.4

2.4.5.3.5

2.4.5.3.6

2.4.5.3.7

Processo de Planejamento de Projeto ………………………………………………………………………69

Processo de Avaliação e Controle de Projeto……………………………………………………………..70

Processo de Gerenciamento de Decisão……………………………………………………………………70

Processo de Gerenciamento de Risco,………………………………………………………………………70

Processo de Gerenciamento de Configuração ……………………………………………………………71

Processo de Gerenciamento de Informação………………………………………………………………71

Processo de Medição ……………………………………………………………………………………………..71

2.4.5.4 Processos Técnicos ………………………………………………………………………………………………………..71

2.4.5.4.1

2.4.5.4.2

2.4.5.4.3

2.4.5.4.4

2.4.5.4.5

2.4.5.4.6

2.4.5.4.7

2.4.5.4.8

2.4.5.4.9

2.4.5.4.10

2.4.5.4.11

Processo de Definição de Requisitos de Stakeholder…………………………………………………..72

Processo de Análise de Requisitos ……………………………………………………………………………72

Processo de Design de Arquitetura;………………………………………………………………………….72

Processo de Implementação……………………………………………………………………………………73

Processo de Integração …………………………………………………………………………………………..73

Processo de Verificação…………………………………………………………………………………………..75

Processo de Transição…………………………………………………………………………………………….76

Processo de Validação…………………………………………………………………………………………….76

Processo de Operação…………………………………………………………………………………………….76

Processo de Manutenção………………………………………………………………………………………76

Processo de Descarte……………………………………………………………………………………………76

2.5 RELAÇÃO ENTRE ISO/IEC15288:2008 COM A IEEE-STD-1220:2005 ………………………………. 77

2.5.1 Ciclo de Vida ……………………………………………………………………………………………. 78

2.5.2 Processos do Ciclo de Vida…………………………………………………………………………. 78

2.5.3 Recursividade…………………………………………………………………………………………… 78

2.6 ENGENHARIA DE SISTEMAS ESPACIAIS SEGUNDO AS NORMAS ECSS……………………………………. 79

2.6.1 Engenharia de sistemas…………………………………………………………………………….. 80

2.6.2 Ciclo de Vida ……………………………………………………………………………………………. 81

2.6.3 Testes em Engenharia Espacial…………………………………………………………………… 83

2.6.4 Documentos de Engenharia de sistemas……………………………………………………… 84

2.6.4.1

2.6.4.2

Documentos de Missão ………………………………………………………………………………………………….85

Documentos de especificação…………………………………………………………………………………………86

xxxi

2.6.4.3

2.6.4.4

2.6.4.5

Documentos de planejamento………………………………………………………………………………………..86

Documentos de definição de projeto……………………………………………………………………………….87

Documentos de justificação de projeto…………………………………………………………………………….88

2.7 MODELOS DE DESENVOLVIMENTO …………………………………………………………………………… 89

2.7.1 Modelo Sequencial……………………………………………………………………………………. 89

2.7.2 Modelo Incremental …………………………………………………………………………………. 91

2.7.3 Modelo Evolucionário……………………………………………………………………………….. 92

2.7.4 Comparação entre os modelos…………………………………………………………………… 93

2.8 DESENVOLVIMENTO INTEGRADO DE PRODUTO E PROCESSO …………………………………………….. 94

2.8.1 Introdução ………………………………………………………………………………………………. 94

2.8.2 Princípios Básicos do IPPD …………………………………………………………………………. 94

2.8.2.1

2.8.2.2

2.8.2.3

2.8.2.4

2.8.2.5

Foco ao Stakeholder………………………………………………………………………………………………………95

Desenvolvimento Simultâneo de Produtos e Processo……………………………………………………….95

Planejamento Antecipado e Contínuo do Ciclo de Vida do Produto……………………………………..96

Identificação Proativa de Riscos e Gerenciamento de Risco ………………………………………………..96

Maior flexibilidade em Contratos com Fornecedores. ………………………………………………………..96

2.8.3 Implantação do IPPD ………………………………………………………………………………… 97

2.8.4 Exploração de Conceito – Fase 0…………………………………………………………………. 98

2.8.5 Definição do Programa e Redução de Risco – Fase I …………………………………….. 100

2.9 ENGENHARIA SIMULTÂNEA ………………………………………………………………………………….. 100

2.9.1 Introdução …………………………………………………………………………………………….. 100

2.9.2 Implantação de Engenharia Simultânea…………………………………………………….. 102

2.9.2.1

2.9.2.2

2.9.2.3

2.9.2.4

Iniciadores ………………………………………………………………………………………………………………….103

Suporte Computacional………………………………………………………………………………………………..105

Técnicas de Engenharia Simultânea ……………………………………………………………………………….107

Compartilhamento de dados…………………………………………………………………………………………108

2.10 ANÁLISE ESTRUTURADA E O FRAMEWORK DE VISÃO TOTAL………………………………………….. 109

2.10.1 Dimensão de Análise …………………………………………………………………………….. 114

2.10.1.1

2.10.1.2

2.10.1.3

2.10.1.4

Modelagem ………………………………………………………………………………………………………………114

Modelagem de Produto ……………………………………………………………………………………………..115

Modelagem de Processo…………………………………………………………………………………………….115

Modelagem de Organização………………………………………………………………………………………..116

2.10.2 Dimensão da Estrutura hierárquica…………………………………………………………. 117

2.10.3 Dimensão de Integração………………………………………………………………………… 117

2.10.4 Requisitos e Atributos……………………………………………………………………………. 119

xxxii

2.10.5 Processos Estruturados de Engenharia Simultânea……………………………………. 120

2.10.5.1

2.10.5.2

2.10.5.3

2.10.5.4

Análise de Stakeholder……………………………………………………………………………………………….120

Análise de Requisito …………………………………………………………………………………………………..120

Análise de Funcional…………………………………………………………………………………………………..121

Análise de Implementação………………………………………………………………………………………….122

3 REVISÃO BIBLIOGRÁFICA …………………………………………………………………………………123

3.1 SISTEMAS DE APOIO SEGUNDO A NORMA ISO/IEC15288:2008 …………………………………….. 123

3.1.1 Visão Geral de Sistemas de Apoio……………………………………………………………… 123

3.1.2 Desenvolvimento de Sistemas de Apoio …………………………………………………….. 125

3.2 SISTEMAS DE APOIO SEGUNDO A NASA…………………………………………………………………… 127

4 ESTADO DA PRÁTICA DO DESENVOLVIMENTO DE GSE ………………………………………….133

4.1 INTRODUÇÃO ………………………………………………………………………………………………….. 133

4.2 PROGRAMA CBERS…………………………………………………………………………………………… 135

4.2.1 Breve Histórico do Programa CBERS 3&4 …………………………………………………… 135

4.2.2 Proposta de Análise………………………………………………………………………………… 136

4.2.3 Árvore de Requisitos……………………………………………………………………………….. 138

4.2.4 Fontes de Requisitos de GSE …………………………………………………………………….. 139

4.2.4.1

4.2.4.2

Plano de Desenvolvimento……………………………………………………………………………………………140

Requisitos de Sistema…………………………………………………………………………………………………..143

4.2.4.2.1

4.2.4.2.2

WBS e PBS …………………………………………………………………………………………………………..143

Documentos de Sistema………………………………………………………………………………………..145

4.2.4.3 Documentos de Subsistema/Unidades……………………………………………………………………………145

4.2.5 O Subsistema de Suprimento de Energia – EPSS………………………………………….. 146

4.2.5.1 Requisitos do EPSS……………………………………………………………………………………………………….148

4.2.5.1.1

4.2.5.1.2

Requisitos de Sistema do EPSS……………………………………………………………………………….148

Plano de Testes Elétricos do EPSS …………………………………………………………………………..151

4.2.5.2 Plano de AIT………………………………………………………………………………………………………………..152

4.2.5.2.1

4.2.5.2.2

4.2.5.2.3

4.2.5.2.4

Estado A ……………………………………………………………………………………………………………..155

Estado B………………………………………………………………………………………………………………156

Estado C………………………………………………………………………………………………………………156

Estado D ……………………………………………………………………………………………………………..157

4.2.6 EGSE do CBERS 3&4 ………………………………………………………………………………… 157

4.2.6.1 Visão Geral………………………………………………………………………………………………………………….157

4.2.6.1.1 Interfaces EGSE ……………………………………………………………………………………………………161

4.3 SGDC…………………………………………………………………………………………………………… 161

xxxiii

4.3.1 Introdução …………………………………………………………………………………………….. 162

4.3.2 A Organização Desenvolvedora – Thales Alenia Space ………………………………… 163

4.3.2.1 Gerenciamento de Processos………………………………………………………………………………………..164

4.3.3 O satélite SGDC………………………………………………………………………………………. 165

4.3.4 O Processo de Engenharia de sistemas………………………………………………………. 167

4.3.4.1 Fase Plateau………………………………………………………………………………………………………………..170

4.3.5 Fontes de Requisitos de GSE …………………………………………………………………….. 173

4.3.5.1

4.3.5.2

Banco de Dados do Satélite…………………………………………………………………………………………..174

AIT……………………………………………………………………………………………………………………………..177

4.3.5.2.1

4.3.5.2.2

4.3.5.2.3

4.3.5.2.4

4.3.5.2.5

Definição de AIT …………………………………………………………………………………………………..178

Entradas do Processo de Preparação de AIT…………………………………………………………….179

Preparação de AIT ………………………………………………………………………………………………..180

Sequência de AIT de Satélite de Comunicações………………………………………………………..180

Lançamento…………………………………………………………………………………………………………183

4.3.5.3 Outras Fontes de Requisitos para GSE…………………………………………………………………………….187

4.3.6 Desenvolvimento de GSE …………………………………………………………………………. 187

4.3.6.1 EGSE…………………………………………………………………………………………………………………………..188

4.4 PROGRAMA PMM……………………………………………………………………………………………. 190

4.4.1 Satélite Amazonia-1………………………………………………………………………………… 190

4.4.2 EGSE Amazônia………………………………………………………………………………………. 192

4.4.3 SCS SCOE……………………………………………………………………………………………….. 195

5 O GUIA DE DESENVOLVIMENTO DE GSE PROPOSTO……………………………………………..199

5.1 OBJETIVOS……………………………………………………………………………………………………… 199

5.2 INTRODUÇÃO ………………………………………………………………………………………………….. 199

5.3 FUNDAMENTAÇÃO DO GUIA ………………………………………………………………………………… 201

5.3.1 Engenharia de sistemas…………………………………………………………………………… 204

5.3.1.1

5.3.1.2

5.3.1.3

5.3.1.4

Modelo de Desenvolvimento ………………………………………………………………………………………..207

Processo de Engenharia de Sistemas Aplicado ao Produto Espacial……………………………………208

Processo de Engenharia de Sistemas Aplicado ao Processo de AIT……………………………………..209

Processo de Engenharia de Sistemas Aplicado ao GSE………………………………………………………211

5.3.2 Abordagem de Sistemas Abertos………………………………………………………………. 214

5.3.3 Desenvolvimento Simultâneo …………………………………………………………………… 214

5.3.4 Interfaces Organizacionais ………………………………………………………………………. 218

5.3.4.1

5.3.4.2

Interface Cliente-Fornecedor ………………………………………………………………………………………..219

Envolvimento Antecipado de Fornecedores…………………………………………………………………….220

xxxiv

5.3.4.2.1

5.3.4.2.2

5.3.4.2.3

Fase de Preparação ………………………………………………………………………………………………221

Fase de Formação ………………………………………………………………………………………………..221

Fase de Gerenciamento e Conclusão ………………………………………………………………………222

5.3.5 Produtos de Apoio de Engenharia de sistemas……………………………………………. 222

5.3.5.1 Documentos de Missão ………………………………………………………………………………………………..223

5.3.5.1.1

5.3.5.1.2

Documentos de Missão para Produto……………………………………………………………………..224

Documentos de Missão de AIT……………………………………………………………………………….224

5.3.5.2 Documentos de Especificação……………………………………………………………………………………….225

5.3.5.2.1

5.3.5.2.2

Documentos de Especificação de Produto……………………………………………………………….225

Documento de Especificação de AIT ……………………………………………………………………….226

5.3.5.3 Documentos de Planejamento ………………………………………………………………………………………227

5.3.5.3.1

5.3.5.3.2

Documentos de Planejamento de Produto………………………………………………………………227

Documentos de Planejamento de AIT……………………………………………………………………..228

5.3.5.4 Dossiê de Definição de Projeto………………………………………………………………………………………230

5.3.5.4.1

5.3.5.4.2

Dossiê de Definição de Produto……………………………………………………………………………..230

Dossiê de Definição de AIT…………………………………………………………………………………….233

5.3.5.5 Dossiê de Justificativa de Projeto…………………………………………………………………………………..236

5.3.5.5.1

5.3.5.5.2

Dossiê de Justificação de Produto…………………………………………………………………………..236

Dossiê de Justificação de AIT………………………………………………………………………………….237

5.3.6 Correlação entre os Produtos de Apoio ……………………………………………………… 238

5.3.6.1

5.3.6.2

5.3.6.3

5.3.6.4

5.3.6.5

5.3.6.6

5.3.6.7

Planejamento de AIT: Interface (1)…………………………………………………………………………………239

Especificação de AIT: Interfaces (2), (3) e (4): ………………………………………………………………….239

Definição de Design de AIT: Interface (5):……………………………………………………………………….240

Realimentação no Design do Produto Espacial: Interface (6): ……………………………………………240

Especificação do GSE: Interfaces (7), (8), (9) e (10):………………………………………………………….241

Realimentação de Requisitos de GSE para Produto Espacial: Interface (11) e (12) :………………242

Realimentação de Justificativa de Design: Interfaces (13) e (14):……………………………………….242

5.4 O PROCESSO DE DESENVOLVIMENTO INTEGRADO DE GSE……………………………………………… 242

5.4.1 Processo de Análise de Sistema – (Satélite)…………………………………………………. 246

5.4.1.1

5.4.1.2

Análise de Implementação (Produto Espacial) – S4 ………………………………………………………….247

Análise de Verificação (Produto Espacial) – S5…………………………………………………………………249

5.4.1.2.1

5.4.1.2.2

5.4.1.2.3

Definir a Estratégia de Verificação – S50………………………………………………………………….251

Identificar Restrições de Verificação – S51 ………………………………………………………………251

Definir Plano de Verificação – S52 ………………………………………………………………………….252

5.4.1.3 Análise de Integração (Satélite) – S6 ………………………………………………………………………………252

5.4.1.3.1

5.4.1.3.2

5.4.1.3.3

Definir a Estratégia de Integração – S60 ………………………………………………………………….253

Identificar Restrições de Integração – S61……………………………………………………………….254

Definir Plano de Integração – S62…………………………………………………………………………..254

xxxv

5.4.2 Processo de Análise de AIT (Satélite em AIT)………………………………………………. 255

5.4.2.1

5.4.2.2

5.4.2.3

5.4.2.4

5.4.2.5

Processo de Análise de Missão de AIT – A0……………………………………………………………………..256

Processo de Análise de Stakeholders de AIT – A1 …………………………………………………………….257

Processo de Análise de Requisitos de AIT – A2 ………………………………………………………………..257

Processo de Análise Funcional de AIT – A3 ……………………………………………………………………..258

Processo de Análise de Implementação – A4…………………………………………………………………..258

5.4.3 Processo de Análise de GSE de Sistema – (Satélite)……………………………………… 259

5.4.3.1

5.4.3.2

5.4.3.3

5.4.3.4

5.4.3.5

Análise de Missão (GSE) – G0 ………………………………………………………………………………………..260

Análise de Stakeholder (GSE) – G1 …………………………………………………………………………………260

Análise de Requisitos (GSE) – G2……………………………………………………………………………………261

Análise Funcional (GSE) – G3…………………………………………………………………………………………262

Análise de Implementação (GSE) – G4 ……………………………………………………………………………262

5.4.4 Loops Externos……………………………………………………………………………………….. 263

5.4.4.1

5.4.4.2

5.4.4.3

5.4.4.4

5.4.4.5

Loop de AIT………………………………………………………………………………………………………………….264

Loop de Acoplamento Funcional…………………………………………………………………………………….265

Loop de Acoplamento de Processo ………………………………………………………………………………..265

Loop de Reuso …………………………………………………………………………………………………………….266

Padronização Entre Projetos …………………………………………………………………………………………267

5.4.5 Processos de Análise de Subsistema………………………………………………………….. 268

5.4.6 Processo de Análise de AIT de Subsistema………………………………………………….. 269

5.4.7 Processo de Análise de GSE de Subsistema…………………………………………………. 270

6 APLICAÇÃO DO GUIA DE DESENVOLVIMENTO INTEGRADO DE GSE…………………………273

6.1 INTRODUÇÃO ………………………………………………………………………………………………….. 273

6.2 PROCESSO DE ANÁLISE DE SISTEMA DO SATÉLITE (S) ……………………………………………………. 276

6.2.1 Cenários do Ciclo de Vida do Satélite…………………………………………………………. 276

6.2.2 Análise de Verificação do Satélite (S5)……………………………………………………….. 277

6.2.3 Análise de Integração do Satélite (S6)……………………………………………………….. 278

6.3 ANÁLISE DO SATÉLITE EM AIT (A)………………………………………………………………………….. 278

6.4 ANÁLISE DO GSE (G)…………………………………………………………………………………………. 279

6.5 ANÁLISE DO UMB SCOE ……………………………………………………………………………………. 285

6.5.1 Análise da Missão do UMB SCOE………………………………………………………………. 285

6.5.1.1

6.5.1.2

Ciclo de Vida do UMB SCOE…………………………………………………………………………………………..286

Cenários do Ciclo de Vida do UMB SCOE…………………………………………………………………………286

6.5.2 Análise de Stakeholder do UMB SCOE – GS2 ………………………………………………. 287

6.5.2.1 Identificação dos Stakeholders de Produto e Processo UMB SCOE……………………………………..287

xxxvi

6.5.2.2

6.5.2.3

6.5.2.4

Identificação dos Stakeholders de Organização do UMB SCOE…………………………………………..293

Stakeholders e suas preocupações…………………………………………………………………………………294

Requisitos de Stakeholders……………………………………………………………………………………………296

6.5.2.4.1

6.5.2.4.2

6.5.2.4.3

Requisitos de Stakeholder para Produto………………………………………………………………….296

Requisitos de Stakeholder para Processo ………………………………………………………………..298

Requisitos de Stakeholders para Organização…………………………………………………………..299

6.5.2.5 Medidas de Efetividade – MOE………………………………………………………………………………………300

6.5.3 Análise de Requisitos do UMB SCOE – GS3………………………………………………….. 302

6.5.4 Análise Funcional UMB SCOE – GS3…………………………………………………………… 305

6.5.4.1

6.5.4.2

6.5.4.3

6.5.4.4

6.5.4.5

6.5.4.6

Identificar as Fronteiras e Interfaces do UMB SCOE………………………………………………………….305

Definir Funções……………………………………………………………………………………………………………308

Análise de Escopo Funcional………………………………………………………………………………………….311

Definir Estados e Modos……………………………………………………………………………………………….315

Análise de Comportamento Funcional ……………………………………………………………………………316

Estabelecer a Arquitetura Funcional do UMB SCOE………………………………………………………….318

7 DISCUSSÃO……………………………………………………………………………………………………321

7.1 COMPARAÇÃO COM ELEMENTOS DA FUNDAMENTAÇÃO TEÓRICA……………………………………… 321

7.1.1 Engenharia Simultânea……………………………………………………………………………. 321

7.1.2 Processos do Ciclo de Vida e Produtos de Apoio………………………………………….. 322

7.2 COMPARAÇÃO COM A PRÁTICA DO PROGRAMA PMM…………………………………………………. 324

7.2.1 Funções Adicionais Identificadas no UMB SCOE pelo PDIG …………………………… 328

7.2.1.1

7.2.1.2

7.2.1.3

Função Alimentar Satélite …………………………………………………………………………………………….329

Função Auxiliar a Calibração………………………………………………………………………………………….330

Funções de Conversão TM e TC……………………………………………………………………………………..332

7.3 ANÁLISE CRÍTICA DA APLICAÇÃO DO GUIA ………………………………………………………………… 335

7.4 LIMITAÇÕES IDENTIFICADAS …………………………………………………………………………………. 335

7.5 CONTRIBUIÇÕES IDENTIFICADAS…………………………………………………………………………….. 336

7.5.1 Abordagem Simultânea no Desenvolvimento de Produto de Apoio……………….. 336

7.5.2 Definição do Processo de AIT……………………………………………………………………. 336

7.5.3 Processo de Desenvolvimento Integrado de GSE…………………………………………. 337

8 CONCLUSÃO ………………………………………………………………………………………………….339

8.1 ATENDIMENTO AO OBJETIVO GERAL……………………………………………………………………….. 339

8.2 ATENDIMENTO AOS OBJETIVOS ESPECÍFICOS……………………………………………………………… 339

8.3 RESUMO DAS CONTRIBUIÇÕES………………………………………………………………………………. 340

xxxvii

8.4 TRABALHOS FUTUROS………………………………………………………………………………………… 340

8.4.1 CONAIT …………………………………………………………………………………………………. 340

8.4.2 Processo de Análise Estruturada do Processo de AIT……………………………………. 342

8.4.3 Processo Desenvolvimento Integrado do GSE Baseado em Modelos ……………… 342

REFERÊNCIAS BIBLIOGRÁFICAS……………………………………………………….……………………...343

GLOSSÁRIO …………………………………………………………………………………………………………351

APÊNDICE A PROCESSO DE ANÁLISE ESTRUTURADA DE SISTEMAS…………………………..353

A.1 INTRODUÇÃO……………………………………………………………………………………………..353

A.2 ANÁLISE DE MISSÃO – P0 ……………………………………………………………………………..355

A.3 ANÁLISE DE STAKEHOLDER – P1 …………………………………………………………………….356

A.4 ANÁLISE DE REQUISITOS – P2………………………………………………………………………..357

A.5 ANÁLISE FUNCIONAL – P3……………………………………………………………………………..358

A.6 ANÁLISE DE IMPLEMENTAÇÃO – P4………………………………………………………………..359

xxxviii

1 INTRODUÇÃO

O objetivo deste capítulo introdutório é apresentar as motivações, os objetivos e as metodologias deste trabalho. Ao final deste capítulo será apresentada também a estrutura deste documento.

Este trabalho versa sobre desenvolvimento de produtos de apoio (enabling

systems), ou seja, como se desenvolve uma classe muito especial de produtos, que são necessários e indispensáveis para montar, operar e testar produtos espaciais.

Este trabalho tem como objetivo sistematizar o processo de desenvolvimento de produtos de apoio para as atividades de montagem integração e testes – AIT (sigla de “Assembly, Integration and Test”) de um produto espacial. Produto de apoio para esse objetivo, são comumente chamadas de Equipamento de Suporte em Solo – GSE (sigla de “Ground Support Equipment”).

Diferentemente dos produtos resultantes do desdobramento de um Sistema de

Interesse, os Produtos de Apoio, são produtos que complementam um Sistema de Interesse durante um ou mais estágios do seu ciclo de vida mas não necessariamente contribuem diretamente com suas funções durante a operação (INCOSE, 2006). Contudo, Produtos de Apoio são indispensáveis para os processos do ciclo de vida do Produto de Interesse e podem possuir design com forte dependência do design do produto de interesse. Essa dependência dificulta seu desenvolvimento pelos métodos tradicionais de engenharia de sistemas e portanto exige uma abordagem diferenciada.

1.1 Motivação

O desenvolvimento de GSE é pouco abordado na literatura, em parte porque

na prática para sistemas de apoio mais acoplados ao produto espacial, o desenvolvimento é feito em conjunto com o produto de interesse dentro de uma mesma organização desenvolvedora, resultando que seu processo de desenvolvimento é marginal ao processo de desenvolvimento do produto de interesse.

1.1.1 Design Acoplado do GSE

No tratamento clássico da engenharia de sistemas o desenvolvimento de um produto segue a estrutura de cima-para-baixo do sistema enquanto que a implementação é de baixo-para-cima EIA-632 (ANSI, 2003).

Normas de engenharia de sistemas, tais como IEEE-Std-1220:2005 e

ISO/IEC15288:2008, tratam de produtos de apoio como resultado da decomposição dos processos do ciclo de vida do produto de interesse conforme mostra a Figura 1.1.

Figura 1.1 – Os processos do ciclo de vida como elementos do sistema

Fonte: Adaptado de IEEE (2005)

A cada elemento decomposto do sistema pode ser aplicada a recursividade do processo de engenharia de sistemas, ou seja, um sistema de apoio é visto como um sistema de interesse e assim são aplicados os processos de engenharia de sistemas para seu desenvolvimento.

Essa maneira de tratar sistemas de apoio pode funcionar para alguns casos mas não necessariamente funciona sempre, pois nela está embutida que na hierarquia do sistema, requisitos fluem do sistema para os elementos, exceto quando há elementos previamente existentes e que devem ser integrados ao sistema (herança), e que a única relação entre elementos de sistema são através das interfaces definidas.

O mesmo pode não ser válido para a relação entre sistema de interesse e sistemas de apoio, onde o design interno de um pode influir no design interno do outro, conforme propõe Halligan (2008).

O mesmo acontece com o GSE, como por exemplo o EGSE de teste de um satélite, onde cada função do satélite e seus subsistemas será operada e testada fazendo uso do EGSE, que deve ter funções especificamente desenvolvidas para isso.

1.1.2 Modelo de Desenvolvimento para GSE

Escolhas inadequadas de modelos de desenvolvimento levam a dificuldades de

escolher e formalizar os pontos de tomadas de decisão em um projeto. A consequência de conduzir revisões superficiais de projeto ou revisões que omitem disciplinas críticas ou mesmo pular o processo de tomada de decisão é normalmente percebido tardiamente e o pior, essa decisão é custosa (INCOSE, 2006).

A aplicação de modelo sequencial no desenvolvimento dos elementos do GSE pode não ser o mais adequado, já que o design interno de um elemento do GSE depende do design interno de um subsistema do satélite conforme abordado por Halligan (2012) na relação do design do sistema de apoio acoplado com a estrutura interna do sistema de interesse e dessa forma os requisitos para o sistema de apoio dependem da solução de design do sistema de interesse, exigindo assim um modelo de desenvolvimento alternativo.

1.1.3 Implementação do GSE

A implementação de um determinado elemento de um sistema pode ser feita de três formas: aquisição/compra, fabricação/desenvolvimento ou reuso. Devido a grande quantidade de desenvolvimentos, a organização desenvolvedora do AIT normalmente demanda a outra organização, interna ou externa, a implementação de determinados elementos do GSE. A norma ISO/IEC15288:2008 estabelece os processos de aquisição e fornecimento de produtos e serviços. Esses processos são perfeitos para a engenharia de sistemas tradicional, marcada por fases bem distintas de seu ciclo de vida, porém, quanto mais os sistemas crescem em complexidade, mais é necessário o desenvolvimento simultâneo de sistemas para que este entre em operação conforme demandado. Na abordagem de engenharia simultânea, os processos de aquisição e fornecimento, embora possam ser aplicados, não conseguem capturar as especificidades necessárias para detalhamento nas interfaces técnicas entre a organizações. Isso ocorre pois durante o desenvolvimento do produto espacial, muitas de suas funções podem não estar completamente definidas o suficiente para definir as funções do equipamento de teste por exemplo.

No desenvolvimento simultâneo é necessário maior flexibilidade e confiança, para que duas organizações possam fazer acordos de aquisição e fornecimento de produtos.

1.1.4 Discrepâncias de GSE

Estudos mostram que a maioria das discrepâncias registradas durante o processo de AIT, 30%, são causadas por problemas de GSE (WEIGEL, 2000). Na prática esse número pode ser ainda maior já que muitas atividades não concluídas por problema de “setup” não são computadas como não-conformidades ocasionando atrasos.

Não-conformidades em AIT de sistemas espaciais detectadas no nível de sistema são consideradas as mais caras para corrigir se comparado a outros níveis de integração (WEIGEL, 2000).

De acordo com Weigel (2000) as não-conformidades detectadas durante o AIT

de um satélite causadas por problemas do GSE são de 29%, conforme pode ser observado na Figura 1.2.

Figura 1.2 – Distribuição das Não-Conformidades em AIT

Eixo Y: Porcentagem da média de discrepâncias normalizada por satélite [%] Eixo X: Área das Discrepâncias: Sistema, Subsistema e Equipamento.

Nota: a categoria GSE esta grafada como “Equipment”) Fonte: Weigel (2000)

Weigel (2000) vai além e estabelece um custo em termos de horas gastas com o processo de não-conformidades e conclui que em média 16 horas são gastas para cada não conformidade registrada (Figura 1.3), e que a maioria dos satélite são gastos entre 2500 a 3000 horas em não conformidades por satélite conforme mostra a Figura 1.4.

Figura 1.3 – Probabilidade de Horas Gastas por Não-Conformidade Baseado em Dados de Entrevista.

Eixo Y: Probabilidade [%]

Eixo X: Horas Gastas por Discrepância [Horas] Fonte: Weigel (2000)

Considerando que 29% dessas não-conformidades são causadas por problemas de GSE, é possível concluir que entre 725 a 870 horas são gastas na média por satélite para o tratamento de não-conformidades casadas por GSE. O que é um número bastante expressivo, mesmo que parte destas não-conformidades não podem ser evitadas apenas com um design melhor do GSE, eles justificam uma atenção maior no desenvolvimento de GSE.

Figura 1.4 – Histograma do Tempo Gasto por Não-Conformidade Por Satélite

Eixo Y: Frequência de Ocorrência

Eixo X: Total de Horas Trabalhadas por Satélite em Discrepâncias no nível de sistemas [Horas] Fonte: Weigel (2000)

1.1.5 Falta de Padronização

Falta de padronização do GSE não permite reuso entre programas e nem

reuso de procedimentos padronizados.

Outro desafio vem do fato de que dentro de um programa espacial, não há justificativa financeira, nem técnica para que o desenvolvimento leve em consideração a reutilização de GSE em programas espaciais futuros. Um programa espacial pode até considerar a reutilização de um GSE já existente, isso gera diminuição de custos, mas jamais dentro de um programa é possível projetar o GSE com visão de padronização para futuro aproveitamento em outros programas devido ao possível impacto no custo final do GSE. Ou seja a diminuição dos custos de curto-prazo forçam o aumento de custos de longo-prazo.

Por outro lado, várias organizações tem sido envolvidas no desenvolvimento de GSE, resultando em soluções não uniformes, de baixo desempenho, e que inviabilizam o reuso entre programas (ALENIA, 2001). A falta de uniformidade também cria dificuldades de integração com os outros elementos do GSE, dificultando sua utilização.

A multiplicidade de soluções, causada pela evolução fragmentada dos sistemas

de testes causam muitos prejuízos á organização como (Amsell,2003):

Ativos Gerenciais – Acúmulo de equipamentos devido a soluções individualizadas para cada programa;
Custos de manutenção – proliferação de software e sistemas proprietários que necessitam de atualizações constantes;
Baixa produtividade – causada pela multiplicidade de sistema de testes. As equipes devem estar familiarizados com muitos sistemas, o que requisita treinamento complexo que resulta em uma grande necessidade de pessoal;

1.1.6 Falta de Dossiê de Definição de AIT

Embora as normas de engenharia de sistemas tais como a IEEE-Std-1220:2005 e ISO/IEC15288:2008 tratem os processos do ciclo de vida como elementos do sistema a serem desenvolvidos, há poucas diretivas para a aplicação do processo de engenharia de sistemas aos processos do ciclo de vida, resultando em escassa documentação requisitada, quando comparado com produtos de interesse. Para o processo de AIT, por exemplo, não há exigência de entrega de documentos de definição, modelos ou simuladores para descrever as definições detalhadas de design da solução proposta para o processo de AIT mas apenas o plano de AIT e seus procedimentos e relatórios.

1.2 Objetivos Específicos

Propor um guia de aplicação de Engenharia de Sistemas para desenvolvimento de GSE segundo a abordagem de Engenharia Simultânea;
Propor um processo desenvolvimento que integre o desenvolvimento do GSE ao desenvolvimento do produto espacial e seu processo de AIT;
Aplicar o guia e o processo a um desenvolvimento de GSE;

Discutir as implicações do guia e do processo para o desenvolvimento de GSE considerando o estado da prática.

1.3 Metodologia

A natureza deste trabalho é de Pesquisa Aplicada ao objetivar a geração de conhecimento para aplicação prática de um problema específicos (SILVA; MENEZES, 2005).

A forma de abordagem do problema é qualitativa ao considerar que há relação dinâmica entre o mundo real e o objeto desta pesquisa, i.e., desenvolvimento de GSE, que não pode ser traduzido em números (SILVA; MENEZES, 2005).

Os objetivos deste trabalho tem caráter de Pesquisa Exploratória ao proporcionar maior familiaridade com o problema e envolver levantamento bibliográfico, coleta de experiências práticas, construção de hipóteses e Estudos de Caso (SILVA; MENEZES, 2005).

Os procedimentos técnicos adotados foram:

Levantamento bibliográfico:

Engenharia de Sistemas segundo as principais manuais e normas internacionais;
Sistemas complexos: Abordagens, métodos e processos relacionados á Engenharia Simultânea, Desenvolvimento Integrado de Produto e Análise Estruturada;

Coleta de experiências práticas :

Estudo de Campo:

Desenvolvimento de GSE segundo atores relevantes na área: o AIT e desenvolvimento GSE no Programa CBERS;

o Engenharia de sistemas do satélite SGDC.

Construção de hipóteses:

Guia de aplicação para desenvolvimento do GSE: o Engenharias de Sistemas;

o Engenharia Simultânea; o Sistemas Abertos;

o Interfaces Organizacionais.

Aprimoramento do processo Análise Estruturada de Sistema para: o Produtos de apoio;

o Processo de AIT.

1.4 Estrutura do Documento

Este trabalho está estruturado em 8 capítulos da seguinte forma:

O Capítulo 1 introduz o assunto e fornece uma visão geral da motivação, do objetivo e da metodologia deste trabalho.

O Capítulo 2 fornece um resumo da fundamentação teórica dos principais

assuntos abordados por esta dissertação.

O Capítulo 3 faz uma revisão bibliográfica sobre o desenvolvimento de sistemas de apoio.

O Capítulo 4 mostra o estado da prática do processo de AIT de Sistemas Espaciais e descreve os principais programas espaciais brasileiros em termos de desenvolvimento de GSE.

O capítulo 5 apresenta um guia de aplicação de engenharia de sistemas para desenvolvimento de GSE.

O Capítulo 6 aplica o guia proposto em um elemento do GSE para o programa PMM.

O Capítulo 7 faz um comparativo dos elementos da fundamentação teórica, da revisão bibliográfica e do estado da prática com o guia proposto para desenvolvimento de GSE, ressaltando as contribuições e limitações deste trabalho.

O Capítulo 8 conclui esta dissertação analisando o atingimento dos objetivos dessa dissertação, ressaltando suas contribuições e limitações principais e apresentando as perspectivas de pesquisa futura relacionada a este trabalho.

2 Fundamentação Teórica

O objetivo deste capítulo é fazer uma revisão dos conceitos utilizados para a realização desta dissertação.

Para atingir esse objetivo foi feito uma revisão da literatura sobre as disciplinas de engenharia de sistemas e engenharia simultânea e mostras as diferentes abordagens de várias entidades relevantes no desenvolvimento de sistemas.

2.1 Engenharia de Sistemas Segundo o DOD

2.1.1 Introdução a Gerenciamento de Engenharia de Sistema

De acordo com o Departamento de Defesa – DOD dos Estados Unidos, um sistema é composto de pessoas, produtos e processos integrados que oferecem uma capacidade para satisfazer uma necessidade ou objetivo (DOD, 2001).

A engenharia de sistemas é uma gestão interdisciplinar de processos de engenharia que evolui e que verifica de forma integrada e balanceada o ciclo de vida de soluções de sistema que satisfaça as necessidades do cliente.

Engenharia de sistemas consiste em duas disciplinas: o domínio do

conhecimento técnico na qual o engenheiro de sistemas trabalha e a gestão da engenharia de sistemas.

As responsabilidades dos engenheiros de sistemas incluem:

Desenvolvimento de uma solução completa de design do sistema que equilibra custo, cronograma, desempenho e risco;
Desenvolvimento e acompanhamento de informações técnicas necessárias para a tomada de decisão;
Verificação de que soluções técnicas que satisfaça as necessidades dos clientes,
Desenvolvimento de um sistema que possa ser produzido economicamente e viável durante todo o ciclo de vida;
Desenvolvimento e acompanhamento de compatibilidade interfaces internas e externas do sistema e subsistemas;
Estabelecimento de baselines e controle de configuração;

Estrutura e foco adequado de projeto para a Equipe Integrada de Produto (IPT) de sistema e a nível de subsistema.

Os objetivos de uma Equipe Integrada de Produtos (IPT) é:

Produzir uma solução de projeto satisfaça os requisitos definidos inicialmente;
Comunicar essa solução de projeto de forma clara, eficaz e em tempo hábil.

Conforme ilustrado na Figura 2.1 a gestão de engenharia de sistemas é

realizado por meio da integração de três atividades principais:

Desenvolvimento Faseado que controla o processo de design e fornece as baselines que coordena o esforço de projeto;
Processos de engenharia de sistema que fornece uma estrutura para resolver problemas de projeto e acompanhamento do fluxo de requisitos por meio do esforço de projeto;
Visão integral do ciclo de vida que envolve os clientes no processo de design e garante que o sistema desenvolvido é viável ao longo de sua vida.

Cada uma das atividades acima é necessária para se obter uma gestão e esforço de desenvolvimento adequados.

Figura 2.1 – As Três Atividades Principais da Gestão de Engenharia de Sistema

Fonte: Adaptado de DOD (2001)

2.1.2 Integração do Ciclo de Vida

A integração do ciclo de vida é necessária para garantir que a solução de

design seja viável ao longo da vida do sistema.

O objetivo de integração do ciclo de vida é conseguido por meio do desenvolvimento integrado, ou seja, exame simultâneo de todas as necessidades do ciclo de vida durante o processo de desenvolvimento.

2.1.3 Funções do Ciclo de Vida

Funções do ciclo de vida são as ações características associadas ao ciclo de vida do sistema:

a) Desenvolvimento;

b) Produção e Construção; c) Implantação;
d) Operação; e) Suporte;
f) Descarte; g) Formação; h) Verificação.

Estas atividades abrangem do início ao fim dos processos de ciclo de vida e estão associados a grandes grupos funcionais que fornecem suporte essencial para o processo de ciclo de vida. Estas funções-chave do ciclo de vida são comumente referidos como os oito principais funções de engenharia de sistemas.

Desenvolvimento inclui as atividades necessárias para desenvolver o sistema a partir de necessidades do cliente para soluções de produtos ou processos;
Fabricação / Produção / Construção inclui a fabricação de modelos de engenharia, de teste , produção em baixa escala inicial, e produção em escala completa de sistemas e produtos finais, ou a construção de sistemas ou subsistemas, grandes ou exclusivos;
Implantação (Fielding) inclui as atividades iniciais necessárias para entregar, transportar, receber, processar, montar, instalar, verificar, operar, armazenar o sistema a fim de alcançar a plena capacidade operacional;

Operação é a função do usuário e inclui atividades necessárias para satisfazer objetivos e tarefas operacionais definidos nos ambientes de paz e de guerra;
Suporte inclui as atividades necessárias para fornecer operações de apoio, manutenção, logística e gestão de materiais.
Descarte inclui as atividades necessárias para assegurar que a eliminação de componentes do sistema desativado, destruído ou irreparável, cumpre todos os regulamentos e diretivas aplicáveis;
Treinamento inclui as atividades necessárias para alcançar e manter o conhecimento e a habilidade a níveis necessários para executar com eficiência e eficácia as operações e funções de apoio.
Verificação inclui as atividades necessárias para avaliar o progresso e a eficácia de evoluir produtos e processos do sistema, e para medir a conformidade com a especificação.

2.1.4 Desenvolvimento Faseado

Dividir o projeto em fases de desenvolvimento tem duas finalidades principais: de controlar o esforço de projeto e de ligar o esforço de gestão técnica e o esforço global de aquisição.

O DOD recomenda a divisão do projeto nos seguintes estágios (DOD, 2001):

Nível de Concepção – que produz a concepção e sua descrição;

Nível de Sistema – que produz a descrição do sistema em requisitos;

Nível Subsistema/Componente – que produz um conjunto detalhado de descrições relativo a sua produção e a especificação do primeiro nível do conjunto de subsistema/componente.

2.1.4.1 Considerações de desenvolvimento nos níveis hierárquico de

sistema

Desenvolvimento significativo em qualquer nível na hierarquia do sistema não deve ocorrer até que as baselines de configuração nos níveis mais elevados são considerados completo, estável e controlada.

Revisões técnicas são feitas para garantir que as baselines estão prontas para o próximo nível de desenvolvimento.

Figura 2.2 – Desenvolvimento Faseado

Fonte: Adaptado de DOD (2001)

2.1.5 O Processo de Engenharia de Sistema

O processo de engenharia de sistemas é o coração da gestão de engenharia

de sistemas. Sua finalidade é fornecer um processo estruturado e flexível, que transforma requisitos em baselines em especificações, arquiteturas, e baselines de configuração.

O Processo de Engenharia de Sistemas (SEP) é um processo abrangente, iterativo e recursivo na resolução de problemas, aplicado sequencialmente de cima para baixo pelas equipes integradas.

Entradas e saídas;

Processo de Análise de requisitos;

Processo de Análise funcional e alocação; o Interação cíclica de Requisitos;
Processo de Síntese;

o Interação cíclica de Design; o verificação;

Processo de Análise de Sistemas e Controle.

Figura 2.3 – Processo de Engenharia de Sistemas

Fonte: Adaptado de DOD (2001)

2.1.5.1 Processo de Análise de Requisitos

O primeiro passo do processo de engenharia de sistemas é analisar as entradas do processo. Análise de requisitos é usado para desenvolver requisitos funcionais, de desempenho, e as restrições de projeto.

Requisitos funcionais definem quantidade, qualidade, cobertura, o momento e a disponibilidade.

Restrições de projeto pode definir quais os fatores que limitam a flexibilidade do projeto, tais como: condições ambientais ou limites regulatórios.

Em geral, a análise requisitos resulta numa melhor compreensão de:

Funções: O que o sistema tem que fazer;

Desempenho: Quanto as funções têm de ser realizados; · Interfaces: Ambiente no qual o sistema irá operar
Outros requisitos e restrições.

Análise de requisitos envolve a definição de necessidades e objetivos dos usuários no contexto da utilização prevista pelo cliente, ambientes, e as características identificadas do sistema para determinar os requisitos paras as funções do sistema.

Requisitos de entrada deve ser abrangente e definido para ambos: os produtos do sistemas e os processos do sistema, tais como desenvolvimento, fabricação, verificação, implementação, operações, suporte, treinamento e descarte (as oito principais funções da engenharia de sistemas).

Requisitos são uma declaração do problema a ser resolvido. Requisitos soltos ou que não possuem restrições dificilmente serão suficientes para concepção de uma solução de design.

2.1.5.1.1 O papel das equipes integradas

Uma quantidade significativa de colaboração entre vários usuários de todos os ciclo de vida é necessário produzir um documento de requisitos aceitável.

O cliente ou usuário normalmente têm experiência no emprego operacional do produto ou item que está sendo desenvolvido. Normalmente, as necessidades do cliente ou usuário não é clara ou totalmente expressa de uma forma que possa ser diretamente utilizável pelos desenvolvedores.

É pouco provável que os desenvolvedores receberão um problema bem definido do qual eles possam desenvolver a especificação do sistema. Assim, o

trabalho em equipe é necessário compreender o problema e analisar a necessidade. É imperativo que os clientes façam parte da equipe de definição.

Por outro lado, muitas vezes os clientes acham mais fácil descrever uma solução de sistema que resolva o problema, em vez de descrever o problema em si. Embora essas “soluções” pode ser viável, em certa medida, a melhor solução é obtida por meio de um esforço de desenvolvimento técnico adequado que equilibra apropriadamente os vários objetivos, funções, MOEs, MOSs e restrições da missão do cliente.

2.1.5.1.2 Questões Análise de Requisitos

Análise de Requisitos é um processo de investigação e de decisão. Nesse

processo investigativo algumas perguntas típicas que podem iniciar o processo de pensamento:

Quais são as razões por trás do desenvolvimento do sistema? · Quais são as expectativas dos clientes?
Quem são os usuários e como eles pretendem usar o produto? · O que os usuários esperam do produto?
Qual é o seu nível de especialização e conhecimento do usuários?

Quais são as características ambientais onde o sistema deve obedecer? · Quais são as interfaces existentes e planejados?
Que funções o sistema irá executar, expresso na linguagem do cliente? · Quais são as restrições para o qual o sistema deve obedecer?
O que será a forma final do produto: modelo, protótipo, ou produção em massa?

2.1.5.1.3 Detalhando o Processo de Análise de Requisitos

A norma IEEE-STD-1220:2005 Aplicação e Gerenciamento dos Processos

de Engenharia de Sistemas oferece um processo para a realização de Análise de Requisitos de forma abrangente identificando as tarefas importantes que devem ser executadas . Parte deste processo baseia-se em 15 tarefas de análise de requisitos. Essas tarefas devem ser

cuidadosamente ajustadas para que se adapte ao sistema no qual se está desenvolvendo.

Tarefa 1:

Tarefa 2:

Tarefa 3:

Tarefa 4:

Tarefa 5:

Tarefa 6:

Tarefa 7:

Tarefa 8:

Tarefa 9:

Tarefa 10:

Tarefa 11:

Tarefa 12:

Tarefa 13:

Tarefa 14:

Tarefa 15:

Expectativas do cliente;

Design e restrições organizacionais;

Restrições externas;

Cenários operacionais;

Medida de eficácia (MOE);

Limites do sistema;

Interfaces;

Ambientes de Utilização;

Ciclo de Vida;

Requisitos funcionais;

Requisitos de desempenho;

Modos de operação

Medidas de desempenho de técnico;

Características físicas;

Integração de sistemas Humanos.

Tarefa 1: Expectativas do cliente:

Definir e quantificar as expectativas do cliente. Essas expectativas podem vir de qualquer um das oito principais funções1 da engenharia de sistemas, requisitos operacionais documentos, necessidades de missão, de oportunidade baseado em tecnologia, comunicações diretas com o cliente, ou requisitos de nível de um sistema maior.

1 As oito principais funções da engenharia de sistemas de acordo com o DOD (2001) são: Desenvolvimento, Produção e Construção, Implantação (Fielding), Operação, Suporte, Descarte, Formação e Verificação.

Tarefa 2: Design e restrições organizacionais:

Identificar e definir restrições que impactam soluções de design.

As restrições organizacionais incluem:

Decisões de gestão tomadas em revisão técnica anteriores; · especificações gerais da empresa,
Normas ou diretrizes;

Políticas e procedimentos; · Domínio de tecnologias;
Alocações de recursos físicos, financeiros e humanos para o projeto.

Tarefa 3: Restrições externas:

Identificar e definir restrições externas que impactam soluções de design ou na

implementação das atividades de processo Sistemas de Engenharia. Restrições externas podem incluir:

Leis e regulamentos públicos e internacionais; · Tecnologia,
Os requisitos de conformidade: indústria, internacionais e outras normas · Ameaças a capacidades do sistema;
Capacidades de interfacear com sistemas;

Tarefa 4: Cenários operacionais:

Identificar as interações com o meio ambiente e outros sistemas, e identificar as interconexões físicas com esses sistemas, plataformas e produtos que interfaceiam com o sistema.

Tarefa 5: Medida de eficácia/Adequação (MOE/MOS):

Identificar e definir sistemas de medidas de eficácia e adequação que refletem as expectativas globais e satisfação dos clientes. MOE está relacionado a qualidade com que o sistema deve executar a missão do cliente.

Tarefa 6: Limites do sistema:

Definir os limites do sistema, incluindo:

Os elementos do sistema estão abrangidos e sob controle do projeto; · As interações esperadas entre os elementos do sistema sob o controle

do projeto e com os sistemas que interagem fora do limite do sistema.

Tarefa 7: Interfaces:

Definir as interfaces funcionais e físicas para sistemas, plataformas e/ou produtos externos ou de nível superior em termos quantitativos (incluindo abordagem de sistemas abertos) .

Interfaces também pode ser consideradas a partir de uma perspectiva interna / externa. Interfaces internas são aquelas que abordam elementos dentro dos limites estabelecidos do sistema abordado ao passo que interfaces externas, são aquelas que envolvem relações com entidade fora dos limites estabelecidos.

Tarefa 8: Ambientes de Utilização:

Definir os ambientes para cada cenário operacional. Todos os fatores

ambientais, naturais ou induzidos, que podem afetar o desempenho do sistema.

Tarefa 9: Ciclo de Vida:

Analisar as saídas de tarefas de 1 a 8 para definir os requisitos-chave do

processo de ciclo de vida necessários para desenvolver, produzir, testar, distribuir, operar2, apoiar, treinar, e dispensar os produtos do sistema em desenvolvimento. O uso de equipes integradas que representam as oito funções principais3 .

Foco deve ser sobre os fatores de custo e elementos de maior risco que estão previstos para impactar de suporte e acessibilidade ao longo da vida útil do sistema.

Tarefa 10: Requisitos funcionais:

Definir o que o sistema deve realizar ou deve ser capaz de fazer.

Tarefa 11: Requisitos de desempenho:

Definir os requisitos de desempenho para cada função de nível superior

realizado pelo sistema. O foco principal deve ser dado aos requisitos de desempenho relacionados as MOEs.

Tarefa 12: Modos de operação:

Definir os vários modos de operação para os produtos do sistema em desenvolvimento, bem como as condições que determinam esses modos de operação.

Tarefa 13: Medidas de Desempenho Técnico (TPM):

Identificar os principais indicadores de desempenho do sistema que serão

2 Operar o sistema também é coberta pela tarefa 10.

3 As oito principais funções da engenharia de sistemas de acordo com o DOD são: Desenvolvimento, Produção e Construção, Implantação (Fielding), Operação, Suporte, Descarte, Formação e Verificação

rastreadas durante o processo de projeto. A seleção de TPMs deve ser limitado a crítica

Tarefa 14: Características físicas:

Identificar e definir, por meio de análises, as características físicas que importam e impõe restrições aos produtos do sistema em desenvolvimento.

Tarefa 15: Integração de sistemas humanos:

Identificar e definir considerações humanas que irá afetar o funcionamento dos produtos do sistema em desenvolvimento.

1. ENTRADAS

Requisitos de entrada devem ser abrangentes e definidos para ambos: os produtos do sistemas e os processos do sistema, tais como desenvolvimento, fabricação, verificação, implementação, operações, suporte, treinamento e descarte (as oito principais funções da engenharia de sistemas).

Tipos de Requisitos

Requisitos são classificados de várias maneiras. A seguir, são categorizações

comuns de requisitos relacionados com a gestão técnica:

Requisitos de Usuários4.:

Declarações de fatos e premissas que definem as expectativas do sistema em

termos de objetivos da missão, meio ambiente, restrições e medidas de eficácia e adequação (MOE / MOS).

4 O termo usuários foi utilizado para a traduzir do termo original “customers”. O sentido de “customers” nesse caso é mais amplo e poderia ser confundido com o cliente final do sistema ao passo que o termo usuários é mais abrangente e se refere a qualquer stakeholder do sistema durante o seu ciclo de vida.

Os usuários são aqueles que executam os oito principais funções de engenharia de sistemas com ênfase especial sobre o operador como o cliente-chave

Os requisitos operacionais irão definir as necessidades básicas, no mínimo, responder as seguintes questões:

Implantação operacional:

Perfil da missão/cenário:

Desempenho e parâmetros:

Ambientes de utilização:

Requisitos de efetividade:

Ciclo de vida operacional:

Ambiente:

Onde o sistema será usado?

Como o sistema atingir seu objetivo de missão?

Quais são os parâmetros críticos do sistema para

cumprir a missão?

Como são os vários componentes do sistema a ser

utilizado?

Como eficaz ou eficiente o sistema deve ser para

realizar sua missão?

Quanto tempo o sistema estar em uso pelo usuário?

Que ambientes que se espera que o sistema funcione de

forma eficaz?

Requisitos funcionais:

A tarefa, ação ou atividade necessárias que o sistema deve realizar. Requisitos funcionais identificados na análise dos requisitos serão utilizados como as funções de mais alto nível para análise funcional.

Requisitos de desempenho:

O grau ao qual uma missão ou função deva ser executada. Requisitos de

desempenhos são geralmente medidos em termos de quantidade, qualidade, cobertura e prontidão.

Requisitos de projeto:

Requisitos para os produtos expressos em pacotes de dados técnicos e

manuais técnicos.

Requisitos Derivados:

Requisitos que estão implícitos ou são resultados de transformações de requisitos de nível superior.

Requisitos alocados:

Requisitos que são estabelecidos pela divisão ou alocação de um requisito de alto nível em vários requisitos de nível inferior.

2. SAÍDAS

Os requisitos que resultam da análise de requisitos são tipicamente expressa a partir de uma das três perspectivas ou pontos de vista:

1. Visões operacionais; 2. Visões funcionais;
3. Visões física

Todas as três visões são necessárias e devem ser coordenados para compreender plenamente as necessidades e objetivos dos usuários.

Os requisitos funcionais, em combinação com os requisitos físicos, são as principais fontes dos requisitos que acabará por se refletir na especificação do sistema.

Visão Funcional

A visão funcional foca no “o que” o sistema deve fazer para produzir o comportamento operacional necessário. A visão funcional inclui as entradas, saídas e estados e condições necessárias.

A Visão Funcional inclui:

As funções do sistema;

A performance do sistema:

o Qualitativa (como bom);

o Quantitativa (quanto, capacidade); o Pontualidade (quantas vezes);

Tarefas ou ações a serem executadas; · Inter-relações entre as funções;
Inter-relação funcional entre hardware e software; · Restrições de desempenho;
Requisitos de interface;

hardware ou software original; · Requisitos de verificação.

Visão Física

A visão Física foca em “como” o sistema é construído. É fundamental para estabelecer as interfaces físicas entre os operadores e equipamentos e os requisitos tecnológicos. A visão física normalmente incluem as informações:

A configuração do sistema:

o Descrições de interface,

o Características de painéis de controle;

o Relações entre operadores e o sistema/equipamento;

o Habilidades necessárias do operador para realizar funções atribuídas.

Caracterização dos usuários:

o Desvantagens (ambientes operacionais especial);

o Restrições de uso;

Limitações do sistema físicos:

o Limitações físicas (capacidade, potência, tamanho, peso),

o Limitações da tecnologia (alcance, precisão, taxas de dados, frequência, linguagem);

o Government Furnished Equipment (GFE), Equipamentos Comerciais de Prateleira (COTS), Itens não desenvolvidos (NDI) e requisitos de reutilização;

o Normas necessárias ou dirigidas.

3. FERRAMENTAS

Os meios e ferramentas utilizadas para o processo de análise de requisitos são:

Equipes multidisciplinares de projeto; · Banco de dados:

o de decisão; o de requisitos;

o de descrições de itens do sistema: § Configurações;

Esforços anteriores; · Análise de sistemas e controle.

2.1.5.2 Processo de Análise Funcional e Alocação

Funções são analisadas pela decomposição de funções de alto nível, identificadas por meio da Análise de Requisitos, em funções de nível imediatamente inferior.

Os requisitos de desempenho associados com o nível mais elevado são atribuídos às funções de nível imediatamente inferior. O resultado é uma descrição do produto em termos de “o que” ele faz de forma lógica e em termos

de desempenho desejado. Esta descrição é muitas vezes chamada de arquitetura funcional do produto.

Durante o processo de engenharia de sistemas arquiteturas são geradas para

melhor descrever e compreender o sistema. A palavra “arquitetura” é utilizada em vários contextos no campo geral da engenharia e é usado como uma descrição geral de como os subsistemas se juntam para formar o sistema. Esta descrição é muitas vezes chamada de arquitetura funcional do sistema.

Arquitetura

Em Gestão de Engenharia de Sistemas como desenvolvido o DOD reconhece três arquiteturas universalmente utilizáveis que descrevem aspectos importantes do sistema:

A arquitetura funcional; · A arquitetura física;
A arquitetura do sistema

A Arquitetura Funcional identifica e estrutura os requisitos funcionais e de desempenho.

A Arquitetura Física retrata os produtos do sistema, mostrando como ele é

dividido em subsistemas e componentes.

A Arquitetura do Sistema identifica todos os produtos (incluindo produtos habilitadores5 que são necessários para apoiar o sistema e, por implicação, os processos necessários para o desenvolvimento, produção / construção,

5 Produto de apoio: Tradução do termo original em inglês “Enabling product”, é o nome dado aos sistemas que complementam um sistema de Interesse durante seu ciclo de vida mas não necessariamente contribuem diretamente com suas funções durante operação. (INCOSE, 2006). Exemplo: EGSE;

implantação, operação, suporte, eliminação, formação e verificação.

O processo de Análise Funcional e Alocação possibilita a revisita aos requisitos por meio do processo de Realimentação de Requisitos.

Realimentação de Requisitos

Cada função identificada na análise funcional deve estar rastreada a um requisito de nível superior. Este processo iterativo de revisitar a análise de requisitos como resultado da análise funcional é chamado de Realimentação de Requisitos (tradução do inglês Requirements Loop).

1. ENTRADAS

São as saídas do processo de Análise de Requisitos:

2. SAÍDAS

Arquitetura funcional.

3. FERRAMENTAS

As principais ferramentas disponíveis para a produzir uma arquitetura funcional são:

Diagramas em Blocos de Fluxo Funcional (FFBD) que definem sequências de tarefas e relacionamentos,
Diagramas IDEF0 que definem processos e fluxos de dados;

Diagramas de Análise Temporal (TLS) que definem a sequência temporal de funções críticas;
Folhas de Alocação de Requisitos (RAS) que identificam e rastreiam a

alocação de requisitos;

Gráficos N2 que identificam e permitem analisar as interfaces entre funções; · Diagramas de Fluxo de Dados (DFD) ;
Diagramas de Estado / Modo; · Diagramas de Comportamento.

2.1.5.3 Processo de Síntese de Design

Síntese de design é o processo de definição do produto ou item em termos dos elementos físicos e software que juntos formam e definem o sistema. O resultado desse processo é muitas vezes referido como a arquitetura física.

Nesse processo, conceitos ou designs são desenvolvidos com base nas descrições funcionais que são as saídas do processo de Análise Funcional e Alocação.

O processo Síntese de Design é uma atividade criativa, que desenvolve uma arquitetura física capaz de realizar as funções requisitadas, dentro dos limites dos parâmetros de desempenho prescritos.

A arquitetura física constitui a base para a documentação de definição de

design, como, especificações, referências e estruturas de divisão de trabalho (WBS).

No processo de Síntese de Design dois processos de realimentações são previstas: Realimentação de Design, e Verificação.

Realimentação de Design (Design loop)

Realimentação de Design é o processo de rever a arquitetura funcional para verificar que a concepção física sintetizada pode executar as funções requisitadas.

Verificação

Para cada aplicação do processo de engenharia do sistema, a solução será comparada com os requisitos. A versão da documentação de referência, ou baseline, elaborada durante o processo de engenharia de sistemas deve estabelecer o método de verificação para cada requisito. Cada requisito deve ser verificável no seu nível de desenvolvimento.

Métodos adequados de verificação incluem:

Inspeção;

Demonstração;

Análise (incluindo modelagem e simulação); · Testes.

1. ENTRADAS

Arquitetura Funcional fornecida pelo processo de Análise Funcional e Alocação.

2. SAÍDAS

A saída principal do processo de síntese é a arquitetura física com as seguintes características:

Correlação com análise funcional;

A arquitetura é justificada por estudos “trade off”; · Estrutura da Divisão de Trabalho (WBS);
Métricas para acompanhamento das Parâmetros Chaves de Desempenho (KPP);
Banco de Dados;

3. FERRAMENTAS

Para apoiar o processo de Síntese de Design, várias ferramentas de engenharia, modelagem e análise são disponíveis para documentar o esforço de design:

Folhas de Alocação de Requisitos (RAS); · Folhas de Descrição de Conceitos (CDS)
Diagramas de Blocos Esquemáticos (SBD) · Ferramentas de Engenharia e automação:

o Computer-Aided Design (CAD)

o Computer-Aided-Systems Engineering (CASE) o Computer-Aided-Engineering (CAE)

2.1.5.4 Processo de Análise de Sistemas e Controle

Segundo o DOD, o objetivo do processo de análise de sistemas e controle é garantir que as decisões são feitas após cuidadosa e abrangente avaliação, incluindo análises de risco, recursos do ciclo de vida, efetividade do sistema, requisitos dos stakeholders, cronograma e impacto dos requisitos dos stakeholders em um ambiente de rastreabilidade.

O processo Análise de Sistemas e Controle incluem atividades técnicas de

gestão necessárias para medir o progresso, avaliar e selecionar alternativas, e documentar dados e decisões. Essas atividades se aplicam a todas as etapas do processo de engenharia de sistemas.

A atividades de análise de sistema incluem estudos de trade-off, analisa de

eficiência, e analisa de design. Essas atividades avaliam soluções alternativas para satisfazer requisitos e objetivos técnicos do projeto, além de fornecer uma base quantitativa e rigorosa para a seleção de desempenho, requisitos funcionais e de design.

1. ENTRADAS

Requisitos conflitantes ou de difícil atendimento; · Alternativas de solução;

2. SAÍDAS

As saídas do processo de análise de sistema e controle dependem do nível do desenvolvimento e incluem:

Decisões documentadas (análises de riscos, performance, trade-offs, etc) · Configuração do sistema;
Especificações (apropriada á fase de desenvolvimento); · Configuração dos Processos;
Medidas de desempenho do projeto;

3. FERRAMENTAS

Ferramentas utilizadas para fornecer informações para atividades de análise incluem modelagem, simulação, experimentação e teste.

2.1.6 Estrutura da Divisão de Trabalho (WBS)

A Estrutura da Divisão de Trabalho – WBS (tradução do inglês de Work Breakdown Structure) é um meio de organizar as atividades sistêmicas de desenvolvimento baseadas no sistema e sua respectiva decomposição hierárquica de produtos.

Os processos de Engenharia de Sistemas, descrito anteriormente, produzem

descrições do sistema e seus produtos. Essas arquiteturas de produtos, juntamente com os serviços associados, i.e. gerenciamento de programas, engenharia de sistemas, entre outros, são representados em uma estrutura hierárquica do tipo árvore que é chamada de Estrutura da Divisão de Trabalho ou apenas WBS.

Por ser derivado diretamente das arquiteturas físicas e de sistemas, o WBS poderia ser considerado uma das saídas do processo de engenharia de sistemas, mas o WBS é apresentado aqui como uma das ferramenta de Análise do processo de Análise de Sistemas e Controle por causa de sua

essencial utilidade para todos os aspectos do processo de engenharia de sistemas.

O WBS de um programa é desenvolvido inicialmente para definir os três primeiros níveis hierárquicos, mas com o prosseguimento e desenvolvimento e melhor definição dos elementos, o WBS é estendido para identificar todos os elementos de alto custo e alto risco. Dessa forma o WBS se torna uma ferramenta que possibilita ao contratante gerenciamento e elaboração de relatórios.

2.1.6.1 Objetivos do WBS

Organizacional: A WBS fornece uma visão coordenada, completa e abrangente para gerenciamento do programa.
Negócio: Ele fornece uma estrutura para o calculo de estimativas de custos.
Técnica: A WBS estabelece uma estrutura para: o Identificar produtos, processos e dados;

o Organizar analisar o gerenciamento de risco e seu monitoramento;

o Possibilitar a configuração e gerenciamento de dados (identificação e controle de interfaces)

o Desenvolver de pacotes de trabalho para: serviços, e aquisição de material e componente;

o Organizar revisões técnicas e auditorias.

2.1.6.2 Desenvolvendo o WBS

As arquiteturas devem revisadas e maturadas o suficiente para garantir que todos os produtos e serviços necessários foram identificados, e que a estrutura de cima a baixo fornece um fluxo contínuo de todas as tarefas necessárias para desenvolvimento do projeto.

Os três primeiros níveis da WBS a serem desenvolvidos são:

Nível 1: Sistema Total

Nível 2: Principais Elemento (Segmento)

Nível 3: Componentes subordinados (Itens Prime)

O WBS de um programa tem a parte do “Produto de Interesse” e a parte do “Produto de Apoio”. A parte do Produto de Interesse do sistema tipicamente consiste no(s) produto(s) da missão principal entregue aos usuários6.

A parte do Produto de Interesse do WBS é baseado nas Arquiteturas Físicas

desenvolvida a partir de requisitos operacionais, e representa a parte do WBS envolvida no desenvolvimento do produto.

Por outro lado, a parte “Produto de Apoio” do sistema inclui os produtos e serviços necessários para desenvolver, produzir e suportar o(s) produto(s) de interesse(s). Nesta parte do WBS incluem os elementos horizontais da arquitetura do sistema (excluindo os produtos de interesse), e identifica todos os produtos e serviços necessários para suportar as necessidades do ciclo de vida do produto.

Contrato WBS

Um contrato WBS é desenvolvido pelo Escritório de Gerenciamento do Programa (PMO) em preparação para a contratação dos trabalhos necessários para desenvolvimento do sistema. Um contrato completo de WBS deve incluir os “Produtos de Apoio” necessários.

Concebendo e Rastreando o Trabalho

A utilização principal da WBS é a concepção e acompanhamento do trabalho.

O WBS é uma decomposição lógica de pacotes de trabalhos, usados para

6 O termo original “operational customers” foi traduzido para usuários.

estabelecer qual o trabalho necessário a ser feito e um método organizado de feedback. A matriz de cruzamento do WBS com a estrutura organizacional aponta para os responsáveis pelos pacotes de trabalhos.

Dicionário do WBS

Para cada elemento WBS, uma entrada de dicionário é preparada para que descreva a tarefa, seu custa, e as referências aos números das linha de contrato associados ao parágrafo do documento de Declaração de Trabalho (SOW).

2.1.7 Sistemas Abertos

De acordo com o DOD, 2001, a Abordagem de Sistemas Abertos (tradução livre de “Open System Approach”) é uma abordagem técnica e de negócio que resulta em sistemas que são fáceis de serem alterados ou melhorados pela troca de componentes.

A abordagem de sistemas aberto começou como resultado das profundas mudanças introduzidas pela indústria de informática ao padronizar interfaces e soluções comerciais.

A abordagem de sistemas abertos enfatiza a utilização de interfaces flexíveis e

comerciais para maximizar a interoperabilidade de componentes, com o objetivo de redução de custos.

Do ponto de vista técnico, a abordagem de sistemas abertos aumenta o esforço de projeto com ênfase na engenharia de sistemas, no controle de interfaces e no design modular para a melhoria do design.

Os objetivos e benefícios da abordagem de sistemas abertos são a flexibilização do projeto, redução de riscos, controle de configuração, suporte a longo-prazo e aumento de utilização.

Sistemas Abertos são aqueles utilizam interfaces de padrão aberto, i.e., interfaces sem direito de propriedade, design modular, design de interface que

privilegie soluções múltiplas, componentes de prateleira, itens não desenvolvíveis – NDI (sigla em inglês para “Non-Developmental Items”) e futuro aumento de capacidades.

Figura 2.4 – Exemplo de Sistemas Abertos

Fonte: Adaptado de DOD (2001)

2.2 Engenharia de Sistemas Segundo o NASA

O objetivo desta seção é mostrar como a Engenharia de Sistemas é tratada no manual da NASA de 2007.

A primeira versão do “System Engineering Handbook” da NASA, começou a ser concebido em 1989 durante o programa Ônibus Espacial, tendo sua primeira versão “draft” em 1992 e finalmente publicada em 1995 (NASA,1995).

O objetivo inicial do manual de 1995 era de servir como um guia de Engenharia de Sistemas para NASA, mas mais tarde percebeu-se que e o interesse iria muito além da NASA e seus fornecedores, passando a ser utilizado internacionalmente e educacionalmente.

Os principais objetivos da primeira versão do manual de engenharia de sistemas da NASA eram: (NASA,1995)

Prover informação útil aos engenheiros e gerentes de projetos; 2. Prover descrição genérica de Engenharia de Sistemas da NASA;
Prover uma linguagem comum sobre o processo de engenharia de sistemas;
Prover referência consistente e alinhada a outras fontes de instruções e manuais com NMI 7120.4/NHB 7120.5 “Management of Major System Programs and Projects”.

Em 2007, uma versão revisada foi lançada refletindo a evolução sofrida pela Engenharia de Sistemas e incorporando o padrão ISO 9000, o Modelo de Maturidade em Capacitação – Integração (CMMI) e o retorno de experiência em relatórios de análise e falhas de programas anteriores (NASA, 2007).

O manual deve ser usado em todos os projetos da NASA incluindo projetos internos ou sob contrato, pequenos ou grandes e em várias categorias como Sistema de Voo e Suporte em Solo (FS&GS), Construção de Infraestrutura (CoF) entre outros, mas com ajustes no ciclo de vida de acordo com a especificidades de cada projeto.

O manual é organizado em 6 capítulos, cobrindo fundamentos de engenharia

de sistemas, visão do ciclo de vida de um projeto sob a ótica da NASA, o processo de engenharia de sistemas da concepção ao design, processos transversais de gerenciamento de engenharia de sistemas e outros tópicos específicos em complemento as práticas de engenharia de sistema.

2.2.1 O Processo de Engenharia de Sistemas

Segundo a visão da NASA engenhar um sistema é procurar um design seguro e balanceado em face a interesses opostos e múltiplos ou mesmo conflituosos. Nesse contexto o engenheiro de sistema deve liderar o desenvolvimento da arquitetura do sistema, definindo e alocando requisitos, avaliando alternativas de design, balanceando riscos, definindo e avaliando interfaces e provendo supervisão das atividades de verificação e validação.

Em um contexto geral o Gerenciamento de Projeto é dividido em duas grandes áreas: Engenharia de Sistemas e Controle de Projeto. A Figura 2.5 mostra os 4

processos técnicos de Engenharia de Sistema, á esquerda na figura, os processos específicos do Controle de Projeto, à direita, e os processo comuns a ambas as áreas ao centro.

Os 4 grupos de processos técnicos de Engenharia de Sistemas são dispostos

no Motor de Engenharia de Sistemas da Figura 2.6, que é uma representação gráfica da sequência de dependência dos processos. Os processos de definição do design, à esquerda na Figura 2.6, são aplicados de cima a baixo a todos os produtos na hierarquia de sistema começando pelo produto de nível mais alto e podendo academicamente seguir até o mais baixo.

Os processos de realização, à direita na Figura 2.6, são aplicados de baixo para cima começando pelos produtos mais abaixo na hierarquia do sistema.

Os processos de gerenciamento técnico dos processo, ao centro da Figura 2.6, tem como objetivo de estabelecer e evoluir o planejamento técnico e gerenciar a comunicação e avaliação dos processos de engenharia.

Figura 2.5 – Engenharia de Sistemas no contexto do Gerenciamento de Projeto

Fonte: Adaptado de NASA (2007)

Figura 2.6 – Motor de Engenharia de Sistemas (Motor SE)

Fonte: Adaptado de NASA (2007)

2.2.2 O Ciclo de Vida

A Figura 2.7 mostra as sete fases do ciclo de vida de um projeto. Cada fase é demarcada por Pontos Chaves de Decisão (KDP) (tradução da sigla original “Key Decision Points”) que são eventos onde a autoridade com o poder de decisão, determina se o projeto reuni as condições para passar para a fase seguinte.

O Motor SE é aplicado recursivamente em todas as fases começando pela fase conceitual ou Pré-Fase A. Note que o Motor SE é aplicado integralmente de forma concorrente, i.e., processos de design, processos de realização e os processo de gerenciamento técnico (processos de 1 a 17 na Figura 2.6). Os processos de realização i.e. verificação, validação são aplicados por meio de

modelagem, simulações, maquetes ou outras formas em cima dos conceitos iniciais7.

Figura 2.7 – Ciclo de Vida do Projeto

Fonte: Adaptado de NASA (2007)

O objetivo da fase de estudos conceituais, Pré-Fase A, é de apresentar conceitos viáveis de realização do sistema proposto.

Durante a Fase A, o motor SE é novamente aplicado sobre os conceitos definidos na Pré-Fase A e seus requisitos preliminares e levantar todos os riscos e viabilidades. A fase A termina com a definição dos requisitos de sistema, o conceito de operações (ConOps).

Durante a Fase B, o motor SE é novamente aplicado com o objetivo de maturar a definição do sistema e apresentar seu design preliminar.

A Fase C, utiliza somente o lado esquerdo do motor SE, ou seja os processos de design de sistema para determinar e detalhar o design final do sistema. Os processos de realização do motor SE, lado direito do diagrama da Figura 2.6, são aplicados somente à Fase D, fase de montagem e integração do sistema.

O motor SE é apenas aplicado à fases de operação e descarte, Fases E e F, como forma de retorno de experiência.

Por sua vez, e para garantir que comunicação entre os processos de design e dos processos de realização os processos de gerenciamento técnico, Processo 10 a 17 do diagrama da Figura 2.6, são executados recorrentemente em todas as fases do ciclo de vida do projeto.

7 O manual da NASA ao aplicar o motor SE em um projeto aplica parte dos conceito de Engenharia Simultânea , embora não o cite explicitamente na versão de 2007, o fazia na versão de 1995. Veja discussão na seção 2.2.3.

Cada passada dos processos de design do motor SE, Processo 1 a 4 do diagrama da Figura 2.6, em um nível irá decompor o produto em outros produtos ao nível mais abaixo na hierarquia do sistema, e assim por diante. De acordo com a NASA, dois tipos de produtos são gerados: produtos finais “end product” e os produtos da fase, “phase products” em inglês, ou modelos dos produtos finais.

Para terminar a passada do motor SE, os processos de realização implementação, verificação e validação são aplicados de baixo para cimas na hierarquia dos produtos (Processo 5, 7 e 8 do diagrama da Figura 2.6). Os produtos de fase são então verificados e validados para garantir que o conceito atende à expectativas dos stakeholders. Os processos de verificação e validação aplicados aos modelos (produtos de fase), são a base do planejamento dos mesmos processos aplicado ao produto final na fase D. Esses modelos podem ser usados para serem integrados ao produto do nível acima se necessário.

Na segunda passada do motor SE, os modelos desenvolvidos na passada anterior do motor SE são então integrados ao nível acima na hierarquia do sistema. O processo de implementação somente acontece no produto de fase (modelo) mais baixo da hierarquia do sistema. Nas passada subsequentes do motor SE somente o processo de integração é executado, gerando o produto do nível acima.

No total o motor SE é aplicado cinco vezes ao ciclo de vida do produto sendo que os processo de realização (Processos de 5 a 9) somente são aplicados uma única vez ao produto final na fase D. Outras duas vezes esses processos são aplicados aos modelos, simuladores e maquetes (produtos de fase).

Tabela 2.1 – Ciclo de vida do Projeto de acordo com a nomenclatura da NASA

Fonte: Adaptado de NASA (2007)

2.2.3 Discussão sobre Engenharia Simultânea

O manual da NASA na versão de 1995 citava explicitamente a necessidade de “ambientes automáticos” para lidar com o oneroso reflexo da adoção do enfoque de Engenharia Simultânea conforme fragmentos abaixo:

“Engenharia Simultânea. Se o projeto passar antecipadamente pelos pontos de tomada de decisão prematuramente, provavelmente resultará na necessidade de iteração significativa de requisitos e design muito tarde no processo de desenvolvimento. Isso acontece quando não há envolvimento dos peritos técnicos adequados nas fases iniciais, resultando assim na aceitação de requisitos que não podem ser satisfeitos na seleção dos conceitos de design que não podem ser construídos, testados, mantidos e / ou operados. “(NASA, 1995, grifo do autor).

“Engenharia Simultânea é a consideração simultânea de requisitos de produto e de seus processos, por equipes multidisciplinares engenheiros Especialistas de todas as disciplinas (confiabilidade, manutenção, fatores humanos, segurança, logística, etc) cujos conhecimentos serão eventualmente representados no produto têm importantes contribuições em todo O ciclo de vida do sistema “(NASA, 1995, grifo do autor).

Muitos dos conceitos de Engenharia Simultânea foram incorporados na versão de 2007 embora não sejam citados explicitamente.

Embora o manual de engenharia de sistemas da NASA (NASA,2007) empregue os conceitos de Engenharia Simultânea como a necessidade de envolvimento de equipe integrada, a aplicação simultânea em todos os níveis da hierarquia do sistema e na verificação e validação por meio de simuladores e modelos, não há explicitamente a antecipação dos processos do ciclo de vida, apenas considerações genéricas de requisitos.

No processo de engenharia de sistemas da NASA, somente na Fase B do ciclo de vida do produto é que são produzidos os Planos de Verificação e Validação. Já o Plano de Integração aparece somente como produto na Fase C.

2.3 Engenharia de Sistemas Segundo a Norma IEEE-Std-1220:2005

O objetivo desta seção é apresentar de forma resumida os principais conceitos, escopo e processos suportados pela norma IEEE Std 1220.

2.3.1 Introdução

A norma IEEE-Std-1220:2005 foi inicialmente publicada como uma versão

experimental de uso de em 1995. Após revisão e aprovação em 1998 foi finalmente publicada 1999.

Em paralelo, a Organização Internacional de Padronização – ISO (International Organization for Standardization) e a Comissão Internacional de Eletrotécnica IEC (International Electrotechnical Commission) formaram um grupo e criaram a norma ISO/IEC 15288 em 2002 que fornece toda uma estrutura de processos de engenharia de sistemas.

Posteriormente para harmonizar com a norma ISO/IEC 15288:2002 a norma

IEEE-Std-1220 foi revisada em 2005 que resultou em poucas diferenças em relação a versão de 1998, incluindo pequenos ajustes em alguns termos e escopo.

Dessa forma a norma IEEE-Std-1220:2005 pode ser usada em conjunto e complementando a norma ISO/IEC15288:2008 que é mais abrangente em relação ao ciclo de vida do produto.

De acordo a visão da norma IEEE-Std-1220:2005 “O objetivo fundamental de engenharia de sistemas é fornecer produtos e serviços de alta qualidade e características de desempenho, a um preço acessível, com pessoal adequado, e no prazo”. Nesse sentido o propósito da norma é definir os requisitos do esforço técnico para uma organização desenvolvedora de produtos e processos de suporte ao ciclo de vida de um produto espacial ou comercial.

A norma IEEE-Std-1220:2005 prescreve uma abordagem técnica e integrada

de engenharia de sistemas e engloba todos os departamentos organizacionais

e todas as pessoas envolvidas no projeto a fim de realizar para a atingir o objetivo fundamental.

Atender aos objetivos acima envolve: desenvolver, produzir, testar e apoiar um conjunto integrado de produtos (hardware, software, pessoas, dados, instalações, e materiais) e processos (serviços e técnicas) que seja aceitável aos stakeholders.

2.3.2 Hierarquia de Sistema

De acordo com a norma IEEE-Std-1220:2005 um sistema é composto de elementos (subsistemas e componentes) e suas interfaces. Adicionalmente, elementos incluem as pessoas necessárias ao ciclo de vida do sistema: desenvolver, produzir, testar, operar, entre outros. Dessa forma os processos do ciclo de vida são vistos como subsistemas na hierarquia do sistema. Uma vez identificados processo no ciclo de vida para dar suporte ao produto, o SEP é aplicado igualmente aos produtos e aos processos do ciclo de vida

É importante destacar que os elementos humanos não são identificados na

hierarquia do sistema uma vez que a intenção da hierarquia é identificar os elementos para o qual o sistema está sendo definido, e os sistemas/humanos devem ser endereçados em termos de papel , função e participação nos ciclos de vida: operando, produzindo, entre outros.

Figura 2.8 – Hierarquia dos Elementos de um Sistema

Fonte: Adaptado de IEEE (2005)

O Processo de Engenharia de Sistema – SEP deve ser aplicado em cada nível na hierarquia do sistema onde o elemento do sistema é um item complexo para o qual nenhuma solução de design disponíveis, ou produtor existente, pode ser identificado. Uma vez que um elemento do sistema é identificado como um hardware, software, ou elemento humano, as metodologias de projeto específico de cada disciplina são utilizados para projetar o elemento do sistema.

2.3.3 Building Blocks

A Figura 2.9 mostra a estrutura do sistema e seus elementos em destaque.

Observe que os elementos relacionados ao ciclo de vida do sistema também são parte integrante do sistema, ou seja, elementos devem ser desenvolvidos para dar suporte e atender ao ciclo de vida do sistema.

Figura 2.9 – Os Tijolos Básicos (“Building Blocks”) do Sistema

Fonte: Adaptado de IEEE (2005)

2.3.4 Processos do Ciclo de Vida

De acordo com a norma IEEE-Std-1220:2005, os oito processos funcionais

essenciais do ciclo de vida de um produto são:

Desenvolvimento: Planejamento e execução de sistema e subsistema necessários para evoluir de necessidades dos stakeholders ao produto solução e seu ciclos de vida.
Manufatura: Atividades para fabricação montagem de modelos de engenharia, protótipos e solução de produto e seus produtos do ciclo de vida.
Teste:

a. Atividades de planejamento e avaliação da síntese do produto contra os requisitos e sua arquitetura funcional;
b. Atividades de avaliação das soluções de produto e seus ciclos de vida contra as medida de conformidade de satisfação dos stakeholders;
Distribuição: Atividades para transportar, entregar, montar, instalar, testar, e configurar os produtos para efetuar a transição adequada aos usuários;
Operação: Atividades associadas a utilização do produto ou ciclo de vida;

Suporte: Atividades de abastecimento, manutenção, apoio e gestão de instalações para as operações de manutenção;
Treinamento: Atividades necessária para alcançar e manter o conhecimento, as competências e habilidades necessárias para de forma eficiente e efetiva executar operações, suporte e disposição durante todo o ciclo de vida do sistema. A formação é inclusive das ferramentas, dispositivos, técnicas, procedimentos e materiais desenvolvidos e utilizados para oferecer treinamento para todas as tarefas necessárias.
Descarte: Atividades para garantir que a eliminação ou reciclagem dos subprodutos cumpria regulamentação ambiental aplicável

2.3.5 Requisitos Gerais

Para desenvolver uma solução balanceada que atenda aos requisitos dos stakeholders concomitantemente com os objetivos empresariais e as restrições externas impostas, a organização desenvolvedora deve planejar, implementar e controlar um esforço técnico integrado em conformidade com as diretivas da norma.

O esforço técnico integrado significa que a organização deve:

o Planejar, conduzir e gerenciar o esforço técnico para atender aos requisitos;

o Aplicar o processo de engenharia de sistemas SEP para cada nível da hierarquia do sistema;

o Controlar o processo por meio de: o Revisões técnicas;

o Gerenciamento de risco; o Gerenciamento de dados;

o Gerenciamento de interfaces;

o Gerenciamento de configuração;

o Medidas de progressos baseadas em performance;

o Gerar modelos, protótipos e estudos comparativos (trade-off);

o Gerar design integrado que garanta que o produto possa ser fabricado, testado, entregue, operado, mantido, e propriamente descartado;

o Capturar as saídas de todos os processos e atividades em um repositório de dados integrado.

Para ser capaz de produzir o esforço técnico integrado necessário, a norma estabelece requisitos gerais que a organização deve atender:

o Aplicar o Processo de Engenharia de sistemas – SEP;

o Desenvolver Políticas e Procedimentos de Engenharia de Sistemas para todos os processos que governam a organização. Treinamento deve ser baseado em atividades específicas;

o Planejamento do Esforço Técnico: preparar e implementar e controlar cronograma mestre baseado em eventos, cronogramas detalhados e planos técnicos de áreas específicas;

o Estratégias de Desenvolvimento: Deve ser explorado métodos, tecnologias, eficiência dos ciclos de vida;

o Modelagem e Prototipagem para suporte as decisões, definição de requisitos e análises de design e riscos;

o Capturar e alimentar Repositório Integrado a fim de compartilhar recursos: Pacote de dados integrado, requisitos, arquiteturas, trade-off, cronogramas, treinamentos, entre outros;

o Gerar e documentar Pacote de Dados Integrado para dar suporte aos processos do ciclo de vida, incluindo hardware, software e informação técnica específica dos ciclos de vida;

o Gerar a Árvore de Especificação após arquitetura funcional, incluindo sistemas externos e interfaces;

o Gerar a Árvore de Desenhos que reflita os elementos da arquitetura design e em acordo com a Árvore de Especificações;

o Gerar a Estrutura da Divisão de Sistema (SBS) para ser usada no controle e planejamento dos pacotes de trabalho;

o Esforço de Integração de Engenharia de Sistemas: Organizar times integrados para eficiência e integrar engenharia simultânea de produto e ciclo de vida;

o Conduzir Revisões Técnicas nos vários níveis hierárquicos e ao longo dos seus processos do ciclo de vida para análise e aprovação;

o Aplicar Gerenciamento de Qualidade a todos produtos e processos organizacionais;

o Estabelecer a continua Melhoria de Processos e Produtos consistente com os objetivos organizacionais incluindo: reengenharia, auto-análise organizacional e lições aprendidas.

2.3.6 Aplicando o Processo de Engenharia de Sistemas no Ciclo de Vida

Para que um produto evolua e corrija problemas nos seus ciclo de vida, a

norma IEEE-Std-1220:2005 descreve a aplicação do processo de engenharia de sistemas ao longo ciclo de vida do sistema para desenvolver e suportar os produtos do sistema e seus ciclos de vida, a cada nível da hierarquia do sistema. A Figura 2.10 mostra as fases do ciclo de vida de desenvolvimento e operação de um sistema.

Figura 2.10 – Ciclo de Vida Típico de um Sistema Durante Desenvolvimento e Operação

Fonte: Adaptado de IEEE (2005)

2.3.6.1 Fase de Definição do Sistema:

o Definição de Sistema:

o Conceito: Avaliar alternativas de conceitos e riscos associados;

o Planos de Engenharia Iniciais: planos que reflitam o estágio de detalhes do projeto8 ;

o Subsistemas e Interfaces de Subsistemas: Identificação requisitos de interfaces funcionais9;

o Interfaces Homem-Sistema: requisitos de interfaces incluindo performance, carga de trabalho, restrições de design e usabilidade10;

o Fatores de qualidade do Ciclo de Vida: a longo do ciclo de vida: empacotabilidade, transportabilidade, verificabilidade, usabilidade, mantenabilidade, trainabilidade, entre outros;

o Plantas e Design atualizados. o Especificação:

o De Interface de Sistema, Produto, e Subsistemas; o De Sistema e Produto;

o Preliminar de Subsistema;

o Preliminar Completa de Interfaces Homem/Sistema;

o Preliminar Completa de Força de Trabalho, Pessoal e Treinamento. o Configuração de Baseline:

o Baseline de Sistema;

o Baseline de Design de Subsistema. o Revisões Técnicas:

o Revisão de Conceito Alternativo; o Revisão de Definição de Sistema.

2.3.6.2 Fase de Design Preliminar

o Definição Preliminar de Subsistema;

o Conjuntos (assemblies) e interface entre conjuntos; o Componentes e Interface entre componentes;

o Subsistema e Mitigação de Risco de Componentes;

o Identificação e Mitigação de Interfaces Homem/Sistema; o Fatores de qualidade do Ciclo de Vida;

8 Na definição inicial dos planos de engenharia, a norma faz distinção entre sistemas com e sem antecedentes de sistemas similares. No segundo caso haverá necessidade de evolução dos planos de engenharia enquanto que no primeiro eles já teriam maturidade.

9 Os subsistema e suas interfaces são derivados diretamente de uma arquitetura funcional.

10 O foco em “usabilidade” da interface com o ser humano é destacado também nos fatores de qualidade do ciclo de vida.

o Plantas e Design atualizados; o Especificação de Subsistema;

o Especificação de Sistema e Produto; o Especificação de Subsistema;

o Componente e Interface entre Componentes; o Especificação Preliminar de Componente;

o Atualizar a Especificação Preliminar de Interfaces Homem/Sistema;

o Atualizara Especificação Preliminar de Força de Trabalho, Pessoal e Treinamento;

o Configuração de Baseline: o Baseline de Sistema; o Baseline de Design;

o Baseline de Design de Componente; o Revisões Técnicas:

o Revisão de Subsistema; o Revisão de Sistema.

2.3.6.3 Fase de Design Detalhado

o Definição Detalhada de Subsistema: o Definição de Componente;

o Risco de Componente;

o Identificar Aspectos de Interfaces Homem/Sistema; o Fatores de qualidade do Ciclo de Vida;

o Plantas e Design atualizados; o Especificação:

o Especificação de Sistema, Produto Subsistema e Conjunto; o Especificação de Componente;

o Atualizar a Especificação de Interfaces Homem/Sistema;

o Atualizara Especificação de Força de Trabalho, Pessoal e Treinamento;

o Configuração de Baseline:

o Sistema e Baseline de Design; o Baseline de Fabricação;

o Revisões Técnicas:

o Revisão de Componente; o Revisão de Subsistema; o Revisão de Sistema;

2.3.6.4 Fase de Fabricação, Montagem, Integração e Teste

o Fase de Fabricação, Montagem, Integração e Teste: o Integração e Teste de Sistema:

Montar, Integrar e Testar Componentes e Conjuntos; §Montar, Integrar e Testar Subsistema e Produtos; §Estabelecer os Processos de Ciclo de Vida;

o Análise Baseado nos Testes, Conserto e Re-teste; o Atualização Especificações;

o Atualização Baselines;

o Revisão de Planos de Engenharia; o Revisões Técnicas:

Revisão de Prontidão de Teste (TRR); §Auditorias de Configuração Funcional; §Revisão de Aprovação de Fabricação;

2.3.6.5 Fase de Produção e Suporte

o Fase de Produção e Suporte: o Produto de Sistema;

Deficiências de Produtos e Processos; §Descarte de Materiais e Produtos;

o Suporte:

o Evolução do Sistema;

Revisão de Projeto e Planos de Engenharia; §Atualização de Especificação;
Atualização e Controle das Baselines;

2.3.6.6 Engenharia Simultânea e os Processos do Ciclo de Vida

Nos processos do ciclo de vida, atenção deve ser dada ao itens como ferramentas especiais e equipamentos para a fabricação, manutenção, testes,

instalação ou mesmo equipamentos para treinamento e formação (simuladores, manuais, entre outros)

A norma explicitamente “recomenda” a adoção dos conceitos de engenharia simultânea ao utilizar a palavra “should”, mas não demanda sua adoção como indispensável ao não utilizar a palavra “shall”, conforme pode ser observado no trecho abaixo:

“The enterprise or project should integrate the concurrent design of products and their related life cycle processes. Concurrent engineering should integrate product and process development to ensure that the product(s) are producible, usable, and supportable. Computer-aided engineering tools should be used to support development and manufacturing, and should be integrated into the integrated repository” (IEEE-Std-1220:2005,p.18, grifo do autor).

Tradução:

“A empresa ou projeto deve integrar o design simultâneo de produtos e seus processos de ciclo de vida relacionados. A engenharia simultânea deve integrar o desenvolvimento do produto e do processo para garantir que o(s) produto (s) seja produzível, utilizável e suportável. Ferramentas de engenharia auxiliadas por computador devem ser usadas para apoiar desenvolvimento e manufatura, e devem ser integradas no repositório integrado” (IEEE-Std-1220:2005,p.18, grifo do autor).

De acordo com a norma, o desenvolvimento dos processos de ciclo de vida

deve ser adiado pelo projeto até que os requisitos sejam definidos para os produto, o que é uma contradição com a recomendação anterior, conforme pode ser observado no trecho original e traduzido abaixo:

“The development of life cycle processes should be delayed by the project until requirements are defined for the products the life cycle processes support” (IEEE-Std-1220:2005,p.36).

“O desenvolvimento dos processos do ciclo de vida deve (“should”) se atrasados pelo projeto até os requisitos serem definidos para o produto que os processos do ciclo de vida suportam” (IEEE-Std-1220:2005,p.36)

As fases onde acontece a engenharia simultânea dos processos do ciclo de

vida é mostrado na Figura 2.11.

E acrescenta que embora o desenvolvimento das definições de processo de ciclo de vida não podem ser iniciados antes da definição dos produtos que o suportam, ela deve estar disponível no momento que o processo for iniciado.

A norma ainda presume que os processos do ciclo de vida são “normalmente”

menos complexos que os produtos ao qual o processo deve suportar:

“Como a maioria dos processos do ciclo de vida não são tão complexo como o produto para os quais se destinam, o ciclo de desenvolvimento (dos processos do ciclo de vida) deve ser mais curto e deve estar disponível quando necessário. “(IEEE-Std-1220:2005,grifo do autor)

o Engenharia Simultânea e os Processos do Ciclo de Vida: o Desenvolvimento do Ciclo de Vida:

o Especificação dos Processos do Ciclo de Vida; o Baseline dos Processos do Ciclo de Vida.

Figura 2.11 – Engenharia Simultânea dos Processos do Ciclo de Vida

Fonte: Adaptado de IEEE (2005)

2.3.7 Processo de Engenharia de Sistemas

Esta seção tem como objetivo apresentar resumidamente o processo de engenharia de sistemas conforme a norma IEEE-Std-1220:2005.

A Figura 2.12 apresenta o processo de engenharia de sistemas. O projeto ou organização desenvolvedora deve ajustar o processo, adicionando ou subtraindo atividades de acordo com o escopo e políticas da organização e seus procedimento.

Figura 2.12 – Processo de Engenharia de sistemas – SEP

Fonte: Adaptado de IEEE (2005)

2.3.7.1 Análise de Requisitos

O objetivo do processo Análise de Requisitos é de estabelecer um baseline de

requisitos para estabelecer:

o o que o sistema será capaz de realizar;

o como os produtos do sistema são capazes de executar em termos quantitativos, mensuráveis;

o os ambientes ao qual os produtos do sistema devem operar; o os requisitos das interfaces homem / sistema;

o as características físicas / estéticos;

o as restrições que afetam as soluções de design.

O processo de Análise de Requisitos é um processo bastante extensivo, já que engloba de forma direta e indireta as seguintes atividades:

o Definição das Expectativas dos Stakeholders11;

o Definição das Restrições de Projeto (reuse, equipamentos de prateleira…);

o Definição das Restrições da Organização (politicas, decisões, tecnologias..);

o Definição das Restrições Externas (leis, fator humano, competição…); o Definição de Cenários Operacionais;

o Definição do Perímetro do Sistema; o Definição de Interfaces;

o Definição de Ambiente de Utilização;

o Definição dos Conceitos do Ciclo de Vida; o Identificação da Força de Trabalho;

o Identificação de Treinamento;

o Identificação dos Fatores Humanos que possam impactar o ciclo de vida;

o Identificação de Segurança;

o Identificação Contextualizada de Requisitos Funcionais; o Definição dos Requisitos de Performance;

o Definição dos Modos de Operação;

o Definição das Medidas de Performance Técnica; o Definição das Características de Design;

o Estabelecer a Baseline dos Requisitos;

2.3.7.2 Validação de Requisitos

O processo de validação de requisitos tem os seguintes objetivos:

11 Não há na norma um processo explicito de identificação de stakeholders.

o Comparação com as Expectativas dos Stakeholders; o Comparação com as Restrições e da Organização; o Comparação com as Restrições Externas;

o Identificar Variações e Conflitos;

o Estabelecer Baseline de Requisitos Válido;

2.3.7.3 Análise Funcional

O objetivo da análise funcional é fazer a decomposição funcional para o nível

abaixo que deve ser satisfeito pelos elementos do nível abaixo do design. Para isso o uma clara análise dos requisitos deve ser feita.

o Análise Funcional Contextualizada:

o Análise de Comportamento Funcional; o Definição de Interfaces Funcionais;

o Alocação de Requisitos de Performance; o Decomposição Funcional:

o Definição de Sub-Funções;

o Definição de Modos e Estados de Sub-Funções; o Definição da Linha do Tempo de Sub-Funções; o Definição do Fluxo e Dados e Controle;

o Definição dos Modos de Falhas da Funções e seus Efeitos; o Definição da Monitoramento de Segurança das Funções;

o Estabelecimento da Arquitetura Funcional;

2.3.7.4 Verificação Funcional

O objetivo do processo de verificação funcional é garantir que todos os requisitos funcionais e de performance do sistema, bem como as restrições de design são rastreáveis à arquitetura funcional. A arquitetura funcional servirá de entrada para o processo de síntese. O processo completo de verificação funcional possui as seguinte tarefas:

o Definição de Procedimentos de Verificação; o Verificação Funcional;

o Verificação de Completude da Arquitetura; o Verificação Funcional e de Performance; o Verificação de Satisfação das Restrições; o Identificação de Variações e Conflitos;

o Verificação da Arquitetura Funcional.

2.3.7.5 Síntese

O objetivo do processo de síntese é traduzir a arquitetura funcional para uma arquitetura de design com o arranjo e definição dos elementos do sistema e suas interfaces internas e externas. O processo completo de síntese possui as seguintes tarefas:

o Agrupamento e Alocação de Funções;

o Identificação de Soluções de Design Alternativos; o Avaliação de Segurança e Dano Ambiental;

o Avaliação dos Fatores de Qualidade do Ciclo de Vida; o Avaliação dos Requisitos Tecnológicos;

o Definição do Design e Características de Performance; o Definição das Interfaces Físicas;

o Identificação de Oportunidades de Padronização;

o Identificação de Disponibilidade de Componentes de Prateleira; o Identificação das Alternativas de Comprar/Fazer;

o Desenvolvimento de Modelos e Protótipos;

o Avaliação de Modos de Falha, Efeitos e Criticalidades; o Avaliação das Necessidades de Testabilidade;

o Avaliação da Capacidade de Evolução do Design; o Disponibilização do Design Final;

o Iniciação do Desenvolvimento da Evolução do Design; o Produção do Pacote de Dados Integrado;

o Estabelecimento da Arquitetura de Design.

2.3.7.6 Verificação de Projeto

O processo de verificação de projeto ou design tem por objetivos rastrear os

requisitos alocados aos elementos decompostos do sistema são rastreáveis a arquitetura funcional verificada e que a arquitetura de design satisfaça a baseline de requisitos validada. O processo completo da verificação de design possui as seguintes tarefas:

o Seleção da Abordagem de Verificação;

o Definição da Matrix de Verificação: § Inspeção,

Análise,
Demonstração ou § Teste;

o Definição do Processo de Verificação;

o Estabelecimento do Ambiente de Verificação; o Verificação;

Verificação da Completude da Arquitetura; § Verificação Funcional e de Performance;
Verificação da Satisfação das Restrições; o Identificação das Variações e Conflitos;

o Verificação da Arquitetura de Design dos Processo do Ciclo de Vida;

o Verificação da Arquitetura de Design; o Verificação da Arquitetura de Sistema;

o Estabelecimento de Especificações e Baseline de Configuração; o Desenvolvimento da Estrutura Hierárquica do Produto (PBS).

2.3.7.7 Análise de Sistemas

O processo de análise de sistemas tem como objetivo balancear o design por meio da resolução de conflitos entre requisitos, alocação de performances e avaliação da eficiência das soluções alternativas. Esse processo fornece uma rigorosa base quantitativa para estabelecer um design balanceado. O processo completo de análise de sistemas possui as seguintes tarefas:

o Avaliação dos Requisitos Conflitantes; o Avaliação Funcional Alternativa;

o Avaliação de Design Alternativo;

o Identificação de Fatores de Riscos;

o Definição de Escopo dos Estudos de Avaliação:

o Seleção de Metodologia e Critério de Sucesso; o Identificação de Alternativas;

o Estabelecimento de Estudos de Avaliação Ambiental; o Execução de Estudos de Avaliação:

o Análise dos Custos do Ciclo de Vida;

o Análise dos Custos Efetivo do Sistema;

o Análise de Impacto Ambiental;

o Quantificação dos Fatores de Riscos; o Seleção das Opção de Tratamento de Riscos; o Seleção de Alternativa Recomendada;

o Avaliação da Efetividade do Design; o Avaliação de Impactos.

2.3.7.8 Controle

O objetivo do processo de controle é gerenciar e documentar as atividades do Processo de Engenharia de Sistemas – SEP. Para isso, saídas, resultados, planejamento para conduzir as atividades do SEP gerados pelos especialistas são controladas pelo projeto. O Processo de Controle completo possui as seguintes tarefas:

o Gerenciamento Técnico;

o Gerenciamento de Dados;

o Gerenciamento de Configuração; o Gerenciamento de Interfaces;

o Gerenciamento de Risco;

o Gerenciamento de Performance Baseado em Medidas de Progresso;

o Acompanhar a Análise de Sistema e Dados de Verificação/Teste; o Acompanhar Mudança de Requisitos e de Design;

o Acompanhar a Performance contra os Planos de Projeto; o Acompanhar a Performance contra os Planos Técnicos; o Acompanhar as Métricas de Produto e Processo;

o Atualizar as Baselines de Especificação e Configuração;

o Atualizar as Arquiteturas Funcionais, de Design e de Sistema ; o Atualizar os Planos de Engenharia;

o Atualizar os Planos Técnicos; o Integrar o Repositório.

2.4 Engenharia de sistemas segundo a Norma ISO/IEC15288:2008

O objetivo desta seção é analisar os principais conceitos e recomendações da norma ISO 15228:2008 principalmente no que concerne o desenvolvimento de sistemas de apoio.

2.4.1 Histórico

Introduzida em 2002, a norma ISO/IEC15288 foi revisada em 2008 com o objetivo principal de harmonizar práticas e processos do ciclo de vida da Engenharia de sistemas com os processo da norma ISO 12207:2008 de desenvolvimento de software. A Figura 2.13 mostra de forma simplificada as heranças da norma ISO 15228 na linha do tempo.

Figura 2.13 – Histórico simplificado das normas ISO de Engenharia de Software e de Sistema

2.4.2 Estrutura de Sistema

As relações entre o sistema e os elementos do sistema pode ser exemplificadas por uma hierarquia de 2 níveis.

Para um elemento de sistema mais complexo este pode ser considerado um sistema “A”, e aplicando os processos de ciclo de vida de forma recursiva ao sistema “A” para quebrar sua estrutura para o ponto onde seus elementos de sistemas (“A”) são compreensíveis e gerenciáveis e podem ser implementados ou adquirido.

Figura 2.14 – A Estrutura do Sistema de Interesse

Fonte: Adaptado de ISO/IEC (2008)

2.4.3 Sistema de Apoio

De acordo com norma, “sistemas de apoio dão suporte ao sistema de interesse

durante seus estágios do ciclo de vida e não necessariamente contribuem diretamente para suas funções durante operação”12.

A norma também observa que relação entre o sistema de interesse e seus sistema de apoio podem ser bidirecionais ou não. E adverte que “requisitos de interfaces com sistema de apoio e outros sistemas no ambiente operacional13 podem ser necessários a serem incluídos no requisitos do sistema de interesse”.

12 A definição é um pouco imprecisa, já que utiliza o verbo “suportar” no estágio operacional do ciclo de vida, e gera controvérsia como também notado por Halligan (2008).

13 Observe que a norma admite requisitos de interfaces com sistemas de apoio somente para os ambientes operacionais, ignorando os outros estágios não operacionais do ciclo de vida.

De acordo com a norma não há um tratamento especial para sistema de apoio. Um sistema de apoio, pode ser visto como um sistema de interesse e assim podem ser aplicado os processo do ciclo de vida prescritos para seu desenvolvimento.

2.4.4 Ciclo de Vida do Sistema

Para ciclo de vida a norma ISO/IEC15288:2008 sugere um modelo conceitual de necessidades do sistema: realização, utilização, evolução e descarte.

Dessa forma os ciclos de vida variam conforme a natureza, propósito, uso e

circunstância do sistema e cada estágio do ciclo de vida tem seu propósito e contribuição para o ciclo de vida do sistema.

O ciclo de vida é resultado das ações executadas por pessoas em uma organização no uso de procedimentos e sistemas de apoio. Como suporte, a norma oferece um conjunto de processos chamados de “Processos do Ciclo de Vida” para a definição dos ciclo de vida do sistema.

Figura 2.15 – Comparação do escopo das normas ISO/IEC15288:2008 e IEEE-Std-1220:2005 ao longo do ciclo de vida

Fonte: Adaptado de IEEE (2005)

2.4.5 Processos do Ciclo de Vida

A norma ISO/IEC15288:2008 sugere 25 processos divididos em 4 grupos: processos de Acordo, processos de projeto, processos técnicos e processos organizacionais de apoio ao projeto.

Todos os processos são descritos em termos de escopo, propósito, saídas,

atividades e tarefas que são requisitos, recomendações ou permissões.

Os processos do ciclo de vida da ISO/IEC15288:2008 devem ser aplicados de forma simultânea, interativa e recursiva em um projeto, o sistema de interesse e seus elementos.

A aplicação simultânea dos processos se refere à aplicação em fases

diferentes do mesmo projeto como por exemplo ações de design e de construção, e em diferentes elementos do sistema.

A aplicação recursiva refere-se a aplicação em cada elemento do sistema, como um sistema de interesse.

A aplicação interativa é incentivada para refinamento progressivo das saídas do processo.

Um ponto notório sobre a ISO/IEC15288:2008 é reconhecer que a relação do sistema de interesse com os sistemas de apoio podem ser bidirecionais implicando que o sistema de interesse possa ter requisitos demandados do sistemas de apoio (ISO/IEC15288:2008,p.9).

2.4.5.1 Processos de Acordo

Organizações são produtoras ou usuárias dos sistemas ou ambos simultaneamente. O processo de acordo pode ser menos formal quando o fornecedor e o cliente estão dentro de uma mesma organização. O processos de acordo são:

o Processo de Aquisição e;

o Processo de Fornecimento.

Figura 2.16 – Papeis nos acordos organizacionais

Fonte: Adaptado de ISO/IEC-TR-19760 (2003)

2.4.5.1.1 Processo de Aquisição

O processo de aquisição tem por objetivo obter um produto ou serviço de acordo com os requisitos do adquirente.

2.4.5.1.2 Processo de Fornecimento.

O processo de fornecimento tem por objetivo fornecer um produto ou serviço

que atende aos requisitos acordados.

2.4.5.2 Processos Organizacionais de Apoio ao Projeto

Os processos de Apoio aos Projetos são aqueles que se encarregam de

garantir que os recursos necessários ao apoio de projetos estejam de acordo com as expectativas e interesses da organização. Esses processos são frutos de uma visão estratégica de melhoria dos recursos com objetivo de minimizar riscos e melhorar os negócios.

Os processos de Apoio aos Projetos criam uma imagem robusta da organização pois estabelecem um ambiente onde os projetos são conduzidos, estabelecendo requisitos, recursos e métricas de qualidade. Os processos de Apoio são:

o Processo de Gerenciamento do Modelo do ciclo de vida; o Processo de Gerenciamento de Infraestrutura;

o Processo de Gerenciamento de Portfólio de Projetos; o Processo de Gerenciamento de Recursos Humanos; o Processo de Gerenciamento de Qualidade.

2.4.5.2.1 Processo de Gerenciamento do Modelo do Ciclo de Vida

O Processo de Gerenciamento do Modelo do Ciclo de Vida tem como objetivo definir, manter e garantir a disponibilidade de políticas, processos do ciclo de vida, modelos do ciclo de vida e procedimentos para serem usados pela organização. Esses objetivos devem estar consistentes com os objetivos da organização no suporte aos projetos desenvolvidos pela organização.

2.4.5.2.2 Processo de Gerenciamento de Infraestrutura

O processo de Gerenciamento de Infraestrutura tem com objetivo prover a infraestrutura e serviços de apoio para dar suporte os objetivos da organização e do projeto a longo do ciclo de vida. Este processo define, provê e mantem ativos (instalações, ferramentas, sistema de comunicação e de informação) necessários para os negócios da organização dentro do contexto da norma.

2.4.5.2.3 Processo de Gerenciamento de Portfólio de Projetos

O processo de Gerenciamento de Portfólio de Projetos tem como objetivo iniciar e manter os projetos alinhados com os objetivos da organização, comprometendo investimentos de fundos, recursos e sansões adequadas aos projetos selecionados.

2.4.5.2.4 Processo de Gerenciamento de Recursos Humanos

O processo de Gerenciamento de Recursos Humanos tem com objetivo

garantir que a organização é suprida de recurso humanos suficientes e manter suas competências consistes com os objetivos da organização e seus projetos.

2.4.5.2.5 Processo de Gerenciamento de Qualidade

O processo de Gerenciamento de Qualidade tem como objetivo garantir que produtos, serviços e implementação dos processos do ciclos de vida atentam os objetivos de qualidade da organização e a satisfação dos clientes.

2.4.5.3 Processos de Projeto

O processos de Projetos são aqueles que gerenciam recursos e ativos alocados da organização para um projeto. Normalmente uma multiplicidade de projetos são geridos por uma organização. O Processos de Projeto são divididos em duas categorias: processos de gerenciamento e processos de suporte de projetos.

Os processos de projeto, listados abaixo, estão relacionados como

planejamento, custos, cronogramas e realizações para garantir critérios de desempenho e ações preventivas e corretivas.

Processos de Gerenciamento:

o Processo de Planejamento de Projeto;

o Processo de Avaliação e Controle de Projeto. · Processos de Análise e Controle:

o Processo de Gerenciamento de Decisão; o Processo de Gerenciamento de Risco;

o Processo de Gerenciamento de Configuração; o Processo de Gerenciamento de Informação;

o Processo de Medição.

2.4.5.3.1 Processo de Planejamento de Projeto

O processo de Planejamento de Projeto tem como objetivo produzir e comunicar planos de projetos efetivos, determinando o escopo do gerenciamento e das atividades técnicas do projeto, identificando saídas de

processos, tarefas e produtos, estabelecendo cronogramas incluindo eventos como critérios, e alocando recursos necessários ao projeto.

O processo de Planejamento de Projeto deve definir a infraestrutura e os serviços necessários ao projeto, incluindo plano de aquisição14 dos sistemas de apoio necessários a cada estágio do ciclo de vida do projeto.

2.4.5.3.2 Processo de Avaliação e Controle de Projeto

O processo de Avaliação e Controle de Projeto tem como objetivo determinar o

estado do projeto e direcionar planos para garantir que o projeto cumpra o cronograma dentro do prazo e que satisfaça os objetivos técnicos. Esse processo avalia periodicamente o progresso nos marcos de projeto a fim de detectar variações e propor correções.

A avaliação inclui verificação do real consumo de recursos versus o consumo planejado e da disponibilidade de Sistemas de Apoio e serviços.

2.4.5.3.3 Processo de Gerenciamento de Decisão

O processo de Gerenciamento de Decisão tem como objetivo selecionar e registrar a melhor alternativa nas ações de projeto. Esse processo é evocado toda vez que decisões de projeto de qualquer natureza surgem durante o ciclo de vida do sistema.

2.4.5.3.4 Processo de Gerenciamento de Risco,

O processo de Gerenciamento de Risco tem como objetivo identificar, analisar, tratar e monitorar continuamente quaisquer riscos de projeto e nos ciclos de vida do sistema.

14 No processo de Planejamento de Projeto, não há a tomada de decisão “fazer ou comprar” para os sistemas de apoio, sugerindo apenas a sua aquisição.

2.4.5.3.5 Processo de Gerenciamento de Configuração

O processo de Gerenciamento de Configuração tem como objetivo estabelecer

e manter a integridade de todas as saídas de projeto ou processos e disponibilizá-lo aos entes interessados do projeto.

2.4.5.3.6 Processo de Gerenciamento de Informação

O processo de Gerenciamento de Informação tem como objetivo prover de forma relevante e completa, quando necessário, a informação às partes interessadas de forma segura.

2.4.5.3.7 Processo de Medição

O processo de Medição tem como objetivo coletar, analisar e reportar informação relacionada aos produtos e processos em desenvolvimento dentro da organização, com o objetivo de manter o gerenciamento efetivo dos projetos e de demonstrar qualidade.

2.4.5.4 Processos Técnicos

Os Processos Técnicos da norma são aplicados em desenvolvimento para transformar necessidades dos stakeholders em produto e posteriormente por meio da aplicação do produto, na prestação um serviço para atingir a satisfação do cliente. Os Processos Técnicos podem ser aplicados em qualquer nível hierárquico da estrutura do sistema.

o Processo de Definição de Requisitos de Stakeholder; o Processo de Análise de Requisitos;

o Processo de Design de Arquitetura; o Processo de Implementação;

o Processo de Integração; o Processo de Verificação; o Processo de Transição; o Processo de Validação; o Processo de Operação;

o Processo de Manutenção; o Processo de Descarte.

2.4.5.4.1 Processo de Definição de Requisitos de Stakeholder

O processo de Definição de Requisitos de Stakeholder tem por objetivo

identificar e rastrear os requisitos dos sistema que atendam as necessidades dos usuários e outros stakeholders em um cenário identificado.

O processo identifica os stakeholders envolvidos nos ciclos de vida do sistema, suas necessidades, expectativas e desejos, analisa e transforma em um conjunto comum de requisitos de stakeholders que expressam as interações do sistema terá no ambiente operacional que servirá de base para validação final do sistema15.

2.4.5.4.2 Processo de Análise de Requisitos

O processo de Análise de Requisitos tem como objetivo transformar os requisitos de stakeholders em requisitos técnicos do produto que atendam os stakeholders. Como saída desse processo incluem características e requisitos funcionais e de performance, atributos do produto especificado e a rastreabilidades com os requisitos dos stakeholders16.

2.4.5.4.3 Processo de Design de Arquitetura;

O processo de Design de Arquitetura tem por objetivo sintetizar uma solução que satisfaça os requisitos de sistema. Este processo define e analisa a arquitetura funcional, lógica e física do sistema.

As principais saídas deste processo são:

Baseline de arquitetura;
A identificação e descrição dos elementos que formam o sistema; · Rastreabilidade da arquitetura com os requisitos de sistema;
Base de verificação e integração dos elementos é definida.

15 Apesar de considerar os stakeholders do ciclo de vida, há uma tendência a somente validar no ambiente

operacional. O ciclo de vida e os sistema de apoio são tratados apenas como restrições pela norma.

16 No processo de análise de requisitos da norma ISO/IEC15288:2008 não há descrição de atividades ou

saídas relacionadas à requisitos demandados nos estágios do ciclo de vida não operacionais do produto. Ex.: Pontos de içamento em um satélite, interfaces de testes nos equipamentos etc.

Segundo a norma as atividades para atingir os objetivos deste processo são:

Definir a arquitetura: funcional e física;
Analisar e avaliar a arquitetura: incluindo restrições imposta pelos sistemas de apoio17;
Documentar e manter arquitetura: manter baseline da arquitetura em termos de funções, performance, comportamentos, interfaces etc.

2.4.5.4.4 Processo de Implementação

O processo de Implementação tem por objetivo realizar o elemento do sistema18, transformando comportamentos e interfaces especificadas em um elemento de sistema, construído ou adaptado dentro das restrições impostas e no uso das tecnologias selecionadas.

2.4.5.4.5 Processo de Integração

O processo de Integração tem como objetivo montar um sistema consistente com sua arquitetura, combinando elementos de sistema com o objetivo de criar o produto especificado nos requisitos de sistema.

Este processo possui duas atividades principais: Planejamento da integração e Execução da integração.

2.4.5.4.5.1Planejamento da Integração

Para o planejamento de integração são identificados na norma duas tarefas: (a)

a definição de uma estratégia de integração que minimize o tempo, o custo e o risco19 e (b) a identificação de restrições de design que possam afetar a

17 Novamente a norma ISO/IEC15288:2008 cita sistema de apoio apenas como impondo restrições, praticamente repetindo no processo de design a mesma atividade constante no processo de análise de requisitos de stakeholders da 2.4.5.4.1.

18 O processo de implementação somente é aplicado aos elementos de sistemas conforme definido na Seção 2.4.2, elemento de sistema é uma parte discreta de um sistema que poder ser implementado para atender os requisitos especificados.

19 O processo de planejamento integração apresentado na norma, talvez válido para a indústria, trata de forma simplificada o planejamento da integração, ao apenas apontar como saída a estratégia de integração.

estratégia de integração adotada, incluindo fatores como acessibilidade, requisitos de interface com os sistemas de apoio20.

Outro aspecto previsto e bem observado na norma é a progressividade e consequente interdependência da realização da integração em conjunto com a realização da verificação, conforme a progressão da integração dos elemento de sistema.

2.4.5.4.5.2Execução da Integração

A atividade de execução da integração lista cinco tarefas:

Obter os materiais e os sistema de apoio21de acordo com o plano;

Obter os elementos de sistema em acordo com cronograma;
Garantir que os elementos de sistemas foram verificados22e validados23; 4. Integrar os elementos de sistema de acordo com o ICD e procedimento

de integração24 25;

Analisar, registrar e reportar dados de integração, incluindo resultados, não conformidades e ações corretivas.

20 A norma destaca a possibilidade de sistemas de apoio imporem requisitos de acessibilidade e interface ao sistema de interesse, porém não levanta a possibilidade de os sistemas de apoio (processos do ciclo de vida associados e produtos de apoio), imporem requisitos funcionais ao sistema de interesse. A norma também não especifica saídas do processo relacionadas a isso e nem como os requisitos identificados são realimentados ao processo de Análise de Requisitos apresentado na seção 2.4.5.4.2.

21 A norma não atribui ao processo de análise e controle de projeto, 2.4.5.3.2 a responsabilidade pela disponibilidade dos sistemas de apoio.

22 A demonstração da verificação deve ser executado pelo processo de fornecimento apresentado na 2.4.5.1.2.

23 Não esta claro como é feita a validação individual de um elemento de sistema.

24 A norma não esclarece, mas os procedimentos de integração é que devem estar em acordo com o ICD “as-built” do elemento de sistema, porém antes de integrar deve-se inspecionar e certificar-se que o elemento de sistema está em acordo com o ICD.

25 A norma não mostra em qual processo os procedimento de integração são preparados.

2.4.5.4.6 Processo de Verificação

O processo de Verificação tem por objetivo confirmar, por meio de evidencias e

demonstrações que os requisitos de design são atendidos pelo sistema. O processo de verificação é divido em duas atividades: Planejamento da Verificação e Execução da Verificação.

2.4.5.4.6.1Planejamento da Verificação

Na atividade de planejamento da verificação são identificados 3 tarefas: (a)

definição da estratégia de verificação, (b) definição do plano de verificação, e (c) identificação de possíveis restrições devido as motivos práticos tais como precisão, incertezas, método de medição, entre outras, impostas pelos sistemas de apoio26.

2.4.5.4.6.2Execução da Verificação

A atividade de execução da verificação lista 4 tarefas:

Garantir que os sistema de apoio de verificação, infraestrutura, e operadores27estão disponíveis;
Conduzir a verificação para demonstrar o atendimento aos requisitos de design do sistema28;
Disponibilizar os dados de verificação, em acordo com o acordo e regulamentação;
Analisar, registrar e reportar verificação, discrepâncias e ações de correções.

26 A norma não prevê possíveis requisitos impostos aos sistema de interesse pelos processos do ciclo de vida e seus sistemas de apoio, apenas a possíveis restrições.

27 A norma não explicita, porém o texto parece induzir em verificação por meio de teste ou inspeção, ao não considerar nesse processo outras formas de verificação como análise, similaridades.

28 A norma não faz distinção de requisitos de verificação e requisitos de design. Também não há menção a verificação nas variações de ambientes ao qual o sistema está imposto.

2.4.5.4.7 Processo de Transição

O processo de Transição tem como objetivo entregar, instalar e demonstrar

que o sistema esta apto e pronto para desempenhar os serviços especificado pelos stakeholders no ambiente operacional29. O processo de transição deve considerar a logística de transporte, armazenagem bem como os serviços de instalação em local e data acordado com o cliente.

2.4.5.4.8 Processo de Validação

O processo de Validação tem como objetivo evidenciar que os serviços entregues pelo sistema quando em uso atentem aos requisitos dos stakeholders em seu ambiente operacional.

2.4.5.4.9 Processo de Operação

O objetivo do processo de Operação é utilizar o sistema de forma a entregar

seus serviços. O processo de operação cuida da designação de recursos humanos para operar o sistema e monitorar os serviços e o desempenho do conjunto operador-sistema.

2.4.5.4.10 Processo de Manutenção

O processo de Manutenção tem como objetivo manter a capacidade do sistema de prover serviços. A atividades do processo de manutenção incluem: determinar estratégia de manutenção, registrar e analisar problemas e tomar medidas corretivas, incluindo medidas preventivas.

2.4.5.4.11 Processo de Descarte

O processo de descarte tem como objetivo finalizar a existência do sistema, de forma a desativar e remover o sistema e qualquer dejeto gerado, retornando o

29 A norma considera sistemas de apoio também no estágio operacional do ciclo de vida todo sistema que de suporte aos estágios do ciclo de vida (sem distinção) mas que não contribuam diretamente para as funções do sistema.

ambiente às condições originais ou aceitáveis. Este processo trata da destruição e armazenagem das entidades do sistema, seus sistema de apoio e seus dejetos.

2.5 Relação entre ISO/IEC15288:2008 com a IEEE-Std-1220:2005

O objetivo desta seção é discutir algumas diferenças entre as normas ISO/IEC15288:2008 e IEEE-Std-1220:2005.

Enquanto a norma ISO/IEC15288:2008 define processos para todo o ciclo de

vida do sistema, que podem ser aplicados recursivamente, concorrentemente e interativamente ao sistema e seus elementos, a norma IEEE-Std-1220:2005 foca em transformar necessidades do cliente em uma solução de sistema, utilizando uma abordagem voltada para desenvolvimento de produto conforme pode ser observados nos trechos abaixo:

“Resumo: Esta Norma Internacional estabelece um “framework” de processo comum para descrever o ciclo de vida de sistemas artificiais. Define um conjunto de processos e terminologia associada para todo o ciclo de vida, incluindo concepção, desenvolvimento, produção, utilização, apoio e descarte. Esta norma também cobre a definição, controle, avaliação e melhoria desses processos. Esses processos podem ser aplicados simultaneamente, iterativamente e recursivamente a um sistema e seus elementos ao longo do ciclo de vida de um sistema. “(Abstract da ISO / IEC15288: 2008, grifo do autor)

“Resumo: As tarefas interdisciplinares, necessárias ao longo do ciclo de vida de um sistema para transformar as necessidades, exigências e restrições do cliente/usuários em uma solução de sistema. Além disso, são especificados os requisitos para o processo de engenharia de sistemas e sua aplicação ao longo do ciclo de vida do produto. O foco desta norma é sobre as atividades de engenharia necessárias para orientar o desenvolvimento do produto, assegurando ao mesmo tempo que o produto seja projetado adequadamente para torná-lo possível de produzir, possuir, operar, manter e, eventualmente, elimina-lo sem riscos indevidos para a saúde ou o meio ambiente.

[…]

Propósito: [..] O conceito de engenharia de sistemas incorporado neste padrão fornece uma abordagem para o desenvolvimento de produtos em um contexto de sistema” (IEEE-Std-1220:2005,grifo do autor) )

2.5.1 Ciclo de Vida

De forma resumida, a ISO/IEC15288:2008 considera todo o ciclo de vida do sistema enquanto a IEEE-Std-1220:2005 foca no desenvolvimento do sistema, incluindo planos e provendo processos para tratar os demais estágios do ciclo de vida do sistema (ISO/IEC15288:2008).

2.5.2 Processos do Ciclo de Vida

A norma IEEE-Std-1220:2005 utiliza o termo “Processos do Ciclo de Vida” para apontar para as necessidades de sistemas para suporte30, que podem surgir durante os oito processos funcionais essenciais do ciclo de vida do produto31, evidenciando a diferença entre os sistemas de suporte dos subsistemas intrínsecos do sistema.

Já na norma ISO/IEC15288:2008 o termo “Processos do Ciclo de Vida”

engloba os 25 processos prescritos, que podem ser usados durante o ciclo de vida do produto.

2.5.3 Recursividade

Embora tanto a norma IEEE-Std-1220:2005 quanto a norma ISO/IEC15288:2008 aplicam a recursividade à hierarquia do sistema, há uma pequena diferença ao objeto dessa recursividade. Para a norma ISO/IEC15288:2008, a recursividade cria a hierarquia do sistema e dos elementos de sistema onde o nível mais alto esta o sistema de interesse.

A norma ISO/IEC15288:2008 utiliza e aplica a recursividade ao conceito de “sistemas de apoio” que complementam o sistema de interesse durante os processos dos ciclo de vida.

30 Sistemas de apoio.

31 Os oito processos funcionais essenciais do ciclo de vida de um produto são desenvolvimento, manufatura, teste, distribuição, operação, suporte, treinamento e descarte (IEEE-Std-1220:2005).

Por outro lado a IEEE-Std-1220:2005 considera sistema formado de “building blocks” que é essencialmente formado de produtos e um conjunto de processos do ciclo de vida, ou seja, uma vez definido os processo são tratados como sistema. Dessa forma a IEEE-Std-1220:2005 é aplicada para o planejamento ao invés de execução (ISO/IEC15288:2008,pg66).

2.6 Engenharia de Sistemas Espaciais Segundo as normas ECSS

Criada em 1975, Agencia Espacial Europeia (ESA) é uma organização

intergovernamental que reúne um total de 22 países membros. Em 1994 a ESA transfere o sistema de padronização para a European Cooperation for Space Standardization (ECSS).

A ECSS organiza o novo sistema de normas em 4 disciplinas: gerenciamento,

engenharia, garantia de produto e o recém criado ramo de sustentabilidade conforme observado na Figura 2.17.

O sistema de padronização ECSS é organizado em 3 níveis:

o Nível 1: Políticas e Princípios:

o Requisitos gerais de política e princípios; o Nível 2: Requisitos:

o Requisitos específicos das disciplinas; o Nível 3 Manuais e Documentos Normativos:

o Guias para interpretação de requisitos para aplicações específicas.

Figura 2.17 – Sistema de padronização ECSS

Fonte: ECSS (2016)

2.6.1 Engenharia de sistemas

Esta seção apresenta a norma da ESA System Engineering General

Requirements – ECSS-E-ST-10C (ECSS,2009) e Project planning and implementation – ECSS-M-ST-10C (ECSS,2009).

Segundo a norma ECSS-E-ST-10C (ECSS,2009), o processo de engenharia de sistemas é “intrinsicamente interativo em todo o ciclo de vida e particularmente nas fases inicias: fase 0, A e B” quando então são feitas análises de várias soluções de cima para baixo com objetivo de aumentar o detalhamento do sistema.

O processo de engenharia de sistemas é aplicado em cada nível da decomposição funcional do sistema, onde requisitos técnico são derivados aos produtos de nível inferior no processo de engenharia de requisito e em um

sentido inverso o processo de verificação aos níveis inferiores completará a verificação dos produtos no nível superior.

O Plano de Engenharia de Sistemas (SEP) é formado por 5 funções:

Integração e Controle;
Engenharia de Requisito; 3. Análise;
Projeto e Configuração; 5. Verificação.

Figura 2.18 – Funções de Engenharia de sistemas e seus perímetros

Fonte: Adaptado de ECSS-M-ST-10C (ECSS,2009)

2.6.2 Ciclo de Vida

O ciclo de vida típico de um produto espacial de acordo com as normas da ESA

(ECSS) é divido em 7 fases conforme é mostrado Figura 2.19.

Embora as atividades de cada fase possam sofrem sobreposições por conta de atividades relacionadas aos produtos dos níveis abaixo, cada fase do projeto

deve ter todas suas atividades relacionadas finalizadas em um evento de revisão, conforme pode ser observado na Figura 2.19.

Figura 2.19 – Ciclo de Vida de um Projeto de acordo com a ESA/ECSS32

Fonte: Adaptado de ECSS‐M‐ST‐10C (2009)

A fase A é demarcada pela Revisão Preliminar de Requisitos (PRR) cujo objetivo é apresentar especificação preliminar de requisitos e os estudos de concepção.

O mesmo deve acontecer aos produtos de nível mais baixo.

A fase B é finalizada com a Revisão Preliminar de Projeto (PDR) e tem como objetivo estabelecer as baselines do projeto.

32 O ciclo de vida da norma ECSS diferem um pouco em relação as manual da NASA, ao considerar as atividades de lançamento como parte da operação.

A Estrutura da divisão de produto deve ser finalizada na fase B segundo a norma ECSS-M-ST-10C (ECSS,2009)33.

Revisões entre PRR e PDR, devem ocorrem em ordem de cima a baixa na hierarquia do produto, enquanto que as revisões de entre a CDR e a AR dever ocorrer de baixo para cima, seguindo modelo V conforme a Figura 2.20.

Figura 2.20 – Ciclo de Vida das Revisões Segundo a ECSS

Fonte: Adaptado de ECSS‐M‐ST‐10C (2009)

2.6.3 Testes em Engenharia Espacial

De acordo com a norma, a experiência tem demonstrado que testes insuficientes ou inadequados aumentam significativamente os riscos do projeto causados pela descoberta tardia de erro de projeto ou erro de manufatura em órbita (ECSS‐E‐ST‐10‐03C:2012).

O teste é parte do processo de engenharia do sistema e deve começar na fase inicial da missão na definição de processo de verificação, na definição da

33 A norma estabelece que durante a fase B que “o PBS deve ser completado”. Isso pode retardar o inicio das atividades dos produtos de nível mais baixo.

sequência e na filosofia de modelos e deve terminar nos testes de performance antes do lançamentos.

2.6.4 Documentos de Engenharia de sistemas

Durante o desenvolvimento de um produto espacial uma série de documentos são produzidos para especificar, planejar, definir e justificar o produto espacial desenvolvido. A norma ECSS-E-ST-10C (ECSS,2009) sugere uma lista mínima de documentos a serem apresentados nas revisões de projeto, conforme mostrado Tabela 2.2. Os documentos entregáveis de engenharia são classificados em 5 categorias:

Documentos de missão;
Documentos de especificação; · Documentos de planejamento;
Documentos de definição de projeto;
Documentos de justificação de projeto.

Tabela 2.2 – Documentos Entregáveis de Engenharia de Sistema

Documento

MDR

PRR

SRR

PDR

CDR

ORR

FRR

LRR

CRR

ELR

MCR

Documento Descrição de Missão

Especificações

Especificações Técnica de Requisitos Preliminares

Especificações Técnica de Requisitos

Documento de Requisitos de Interfaces

Planos de Engenharia de Sistema

Plano Tecnológico

Matriz Tecnológica

Plano de Verificação

Plano de AIT (QM/FM)

Plano de Mitigação de Debris

Outros Planos (anexo D ECSS-E-ST-10)

Doc. Sistema de Coordenadas

Dossiê de Definição de Projeto (DDF)

Árvore de Funções

Árvore de Produto

Árvore de Especificação

Budget Técnico

Especificações Técnica de Requisitos Preliminares para o nível abaixo

Especificações Técnica de Requisitos para o nível abaixo

Dossiê de Definição de Design para o nível abaixo

Doc. Controle de Interface

Manual de Usuário do Produto

Dossiê de Justificação de Projeto (DJF)

Matriz de Traçabilidade de Requisitos (ao nível abaixo)

dossiê de Justificação de Requisitos

Relatório de Conceito de Sistema

Relatórios de Trade-offs

Doc. Controle de Verificação (VCD)

+(1)

Especificação de Teste

Relatório de Análise

Descrição do Modelo Matemático

Relatório de Correlação

Procedimento de Teste

Relatório de Teste

Relatório de Verificação

Dossiê de Justificação de Projeto (DJF) do nível abaixo

Relatório de Revisão de Projeto

Relatório de Inspeção

Especificação do GSE

Pacote de dados do GSE

NOTA: +

(1)

Doc. necessário para revisão. Quando aparece em várias revisões indica crescente maturidade do documento até estar completo (última cruz)

Doc. Limitado à matriz de verificação

Fonte: Adaptado de ECSS-E-ST-10C (ECSS,2009)

2.6.4.1 Documentos de Missão

O objetivo do Documento de Descrição de Missão (MDD) é prover entrada para a posterior seleção de conceitos que satisfaçam a missão durante as interações da especificação preliminar de requisitos técnicos.

O Documento Descrição de Missão (MDD) é preparado nas fases 0 e A pelo organização responsável pela missão e defini o conceito para atender aos requisito preliminares de projeto. O MDD é feito para cada conceito.

O conteúdo mínimos do MDD é

Introdução – propósito e objetivo;
Documentos aplicáveis de referencia; 3. Requisitos técnicos preliminares;
Descrição do conceito – análise da missão, descrição dos elementos; 5. Descrição de cada fase da missão;
Avaliação do desempenho;
Identificação de áreas de riscos.

2.6.4.2 Documentos de especificação

O documento de especificação de requisitos técnicos (TS) tem por objetivo

estabelecer os requisitos operacionais e de performance e associadas restrições em determinado ambiente.

O documento de especificação técnica (TS) exprime os requisitos técnicos congelados a ser satisfeito por uma solução proposta de projeto. O TS deve descrever o produto e seu contexto, incluindo seu ciclo de vida tais como: eventos de AIT, transporte, condições de testes, interface e instalação com o lançador, fase de lançamento , funcionamento em órbita e seu fim de vida.

Introdução – propósito e objetivo;
Documentos aplicáveis de referencia;
Apresentação das necessidades dos usuários; 4. Conceito e apresentação do produto;
Descrição do Ciclo de vida;
Restrições impostas pelo ambiente; 7. Requisitos:

Identificação, · performance,
rastreabilidade, · tolerância,
verificação.”

2.6.4.3 Documentos de planejamento

O objetivo dos Planos de Engenharia de sistemas (SEP) é definir a abordagem, métodos, procedimentos, recursos, e a organização para coordenar e gerenciar

todas atividades técnicas para especificar, projetar, verificar, operar e manter o sistema ou produto em acordo com os requisito do cliente.

O SEP cobre todo o ciclo de vida do sistema ou produto e deve evidenciar os riscos, elementos críticos, tecnologias específicas bem como as comonalidades, e possíveis reuso e padronizações.

Objetivos e Restrições 2. Evolução do Produto
Fases do projeto e o plano de revisões 4. Estratégia de Aquisição
Itens críticos
Entradas de engenharia de sistemas 7. Saídas de engenharia de sistemas 8. Responsabilidades e Organização
Interfaces de Engenharia de sistemas 10.Descrição das atividades de SE 11.Integração das disciplinas de engenharia

2.6.4.4 Documentos de definição de projeto

O objetivo do DDF é definir tecnicamente o sistema ou produto que atenda aos requisitos técnicos especificados. “O Dossiê de Definição de Projeto (DDF) é a estrutura básica com todas e as características e informações da arquitetura física e funcional do sistema ou produto, necessárias para fabricação, utilização, suporte e gerenciamento de configuração. O DDF é uma coleção de toda documentação que estabelece o sistema tais como: especificação do nível abaixo, descrição do design e das interfaces, desenhos, esquemas, modelos, restrições específicas oriundas das soluções adotadas (materiais, processos entre outros).

O DDF detalha a configuração “”as-designed”” e é a referência para produção, AIT, operação e manutenção do sistema.

Descrição sumária dos requisitos do produto;
Descrição das Funções: arquitetura e árvore de funções;
Descrição Física: arquitetura, árvore de produtos e de especificação; 4. Descrição das Interfaces;

Budget, margens e desvios; 6. Restrições do ciclo de vida;
Referência ao banco de dados de engenharia; 8. Manual de usuário.”

2.6.4.5 Documentos de justificação de projeto.

O DJF apresentas os “trade-offs” e análises que dão suporte as decisões de

projeto definidas na DDF. O DJF em conjunto como DDF e TS formam a base para desenvolvimento do produto.

Descrição de projeto;
Justificativa do design: destaque dos requisitos não atendidos, críticos e análises de risco.
Justificativa da Arquitetura funcional; 4. Justificativa da arquitetura física;
Síntese das atividades de desenvolvimento;
Síntese das atividades de verificação (plano de verificação, modelos, evidência de qualificação…);
Justificativa dos budgets;
Justificativa das restrições.”

2.7 Modelos de Desenvolvimento

Todo projeto possui pelo menos dois pontos de decisão: decisão de proceder com o projeto e a decisão final de aceitação do projeto (INCOSE,2006). A organização desenvolvedora do projeto deve decidir quais os estágios do ciclo de vida são mais apropriados para o projeto e quais pontos de decisão, além dos dois básicos de início e fim, são necessários a fim de beneficiar o projeto.

Vários modelos de desenvolvimento tais como cascata, espiral, modelo “Vê” e

modelo Ágil, são úteis para definirem os pontos de início e fim e as atividades apropriadas dos estágios do ciclo de vida de um projeto.

Nas próximas seções são apresentados os principais modelos de desenvolvimento de projetos e suas principais características, benefícios e dificuldades.

2.7.1 Modelo Sequencial

O modelo sequencial de desenvolvimento é caracterizado pela progressão de fases distintas e não interativas de realização de um sistema (MACDONALD;BADESCU,2014). Dentro dessa categoria estão o modelo “cascata” e o modelo “Vê”.

O modelo sequencial é indicado para projetos com limitado número de

realizações, e para os quais os requisitos são bem conhecidos no início do projeto e permanece inalterados ao longo do tempo (MACDONALD;BADESCU,2014).

O modelo sequencial é muito utilizado para desenvolvimento de sistemas

nunca antes desenvolvidos ou mesmo para sistema que usam o estado da arte da tecnologia (ISO/IEC-TR-19760:2003).

Projetos que adotam o modelo Vê encontram muitos desafios tais como custo, controle, mudanças de tecnologia, retenção de força de trabalho, mudança de requisitos e satisfação do stakeholder final. Esses desafios aparecem principalmente por conta do longo tempo de desenvolvimento, do

estabelecimento dos requisitos iniciais para a solução de sistema (ISO/IEC-TR-19760:2003).

O modelo sequencial é indicado para sistemas que possuem longo tempo de desenvolvimento acima de 3 ou 5 anos, tais como indústria automobilística ou setor militar (INCOSE,2006).

Figura 2.21 – Modelo Sequencial de desenvolvimento

Fonte: Adaptado de Macdonald e Badescu (2014)

O modelo Vê destaca a definição hierárquica ao mesmo tempo que destaca a necessidade de verificação e validação contínua com os stakeholders e a importância da avaliação contínua de riscos e oportunidades.

A parte central do modelo Vê é a evolução das baselines de requisitos de

usuários à identificação dos conceitos do sistema para definição dos componente que irão integrar o sistema final, como o tempo movendo para a direita e o aumento da maturidade do sistema movendo verticalmente para cima.

Figura 2.22 – Lado Esquerdo e Direito do Modelo em Vê

Fonte: Adaptado de INCOSE (2006)

2.7.2 Modelo Incremental

O modelo incremental é caracterizado pela entrega de versões em intervalos regulares ou planejados. Tipicamente as características e capacidades da última versão entregue é o início do desenvolvimento da versão seguinte. Normalmente as primeiras versões contém características e capacidades limitas de acordo com um planejamento prévio até a entrega do sistema como todas as capacidades (ISO/IEC-TR-19760:2003).

No modelo incremental, os processos do ciclo de vida são aplicados para a

realização de cada versão do sistema, em paralelo à manutenção e suporte da versão anterior.

Uma variante do modelo incremental é o modelo espiral muito utilizado na indústria de software ou quando os requisitos não estão completamente estabelecido e podem alterar ao longo do tempo (MACDONALD;BADESCU,2014).

O modelo espiral pode também ser visto como o modelo cascata aplicado recursivamente para cada versão (MACDONALD;BADESCU,2014), conforme pode ser observado na Figura 2.23.

O modelo espiral é suportado por uma definição bem controlada do documento de controle de interface (ICD). Uma boa definição do documento de interface – ICD permite o desenvolvimento apenas com simuladores para as entradas do sistema. Para isso os simuladores devem ser desenvolvidos e formalizados durante a fase de design (MACDONALD;BADESCU,2014).

Figura 2.23 – Modelo Espiral de desenvolvimento

Fonte: Adaptado de Macdonald e Badescu (2014)

2.7.3 Modelo Evolucionário

O modelo evolucionários também é caracterizado pela entrega de versões em intervalos regulares ou planejados. Tipicamente as características e capacidades da última versão entregue é o início do desenvolvimento da versão seguinte como o modelo incremental.

As diferenças com o modelo incremental é que a capacidade não é completamente conhecida durante seu desenvolvimento.

O modelo evolucionário é indicado para sistemas complexos dos quais os requisitos não estão bem definidos ou até mesmo as necessidades sistema. Exemplos de sistemas que utilizam esse modelo são sistemas de tecnologia da informação, sistemas de defesa e sistemas de segurança (MACDONALD;BADESCU,2014).

2.7.4 Comparação entre os modelos

Tabela 2.3 – Comparação entre os modelos de desenvolvimento

Fonte: Adaptado de ISO/IEC-TR-19760 (2003) e Macdonald, Badescu (2014)

2.8 Desenvolvimento Integrado de Produto e Processo

Objetivo desta seção é apresentar o Manual de Desenvolvimento Integrado de Produto e Processo “Integrated Product and Process Development Handbook” (DOD,1998) produzido pelo Escritório de Tecnologia e Aquisições do Departamento de Defesa (DOD) americano.

2.8.1 Introdução

Em complementação as diretivas do processo de aquisição, e após exame de 80 instituições industriais e governamentais, o DOD lança em 1996 o Guia para Desenvolvimento Integrado de Produto e Processo (IPPD), com objetivo de prover entendimento geral de métodos e técnicas de IPPD. Em 1998 o Guia de IPPD é expandindo para o atual Manual de IPPD, com a inclusão de sugestões e exemplos de práticas específicas para implantação de IPPD.

O Desenvolvimento Integrado de Produto e Processo, também conhecido com

o nome de Engenharia Concorrente ou Engenharia Simultânea, evoluiu na indústria com o objetivo de aumentar a satisfação ao cliente, em um mercado global e competitivo, onde a tempo de desenvolvimento é fator crucial para o sucesso (DOD,1998).

De acordo com o DOD o Desenvolvimento Integrado de Produto e Processo “é

uma técnica de gerenciamento que integra todas as atividades de aquisição começando pela definição de requisitos e permeando a produção, entrega, e suporte operacional, de forma a otimizar o design, a fabricação, os negócios e os processos de suporte” (DOD,1998).

Assim como a Engenharia de Sistemas, o IPPD também é uma abordagem multidisciplinar para processo de resolução de problemas, com a característica de ser mais amplo ao envolver análise financeira e de negócios.

2.8.2 Princípios Básicos do IPPD

O DOD identifica um grupo de princípios básicos para implementar IPPD:

Foco ao stakeholder;

Desenvolvimento simultâneo de produtos e processos;
Planejamento antecipado e contínuo do ciclo de vida do produto; 4. Identificação e gerenciamento de risco;
Maior flexibilidade em contratos com fornecedores.

2.8.2.1 Foco ao Stakeholder

A abordagem do IPPD é direcionada as necessidades dos stakeholders34, sendo o stakeholder final o usuário do sistema, dessa forma, o foco ao stakeholder é conseguido por meio da inclusão dos stakeholder nas decisões e nos times multidisciplinares.

Ferramentas como Variável Independente de Custo – CAIV (tradução livre de “Cost as an Independent Variable”) e Matriz Funcional – QFD (tradução livre de “Quality Functional Deployment”) são eficientes para a definição dos requisitos dos stakeholders.

2.8.2.2 Desenvolvimento Simultâneo de Produtos e Processo

Desenvolvimento simultâneo de produto e processo significa desenvolver conjuntamente e simultaneamente todos os processos necessários para se fazer o produto, ou seja, processos de desenvolvimento e processos de implantação. O enfoque aos processos durante o design garante que o produto não terá custo adicional devido a complicações nesses processos e não levadas em consideração.

Desenvolvimento de produto e processos para satisfazer as necessidades dos stakeholders já é parte da Engenharia de Sistemas. O IPPD expande esta abordagem incluindo não somente os stakeholders de produto mas todos os stakeholders dos processos relacionados ao produto como por exemplo processos financeiros, negócios, contratos etc.

34 Para o DOD (1998), “customers”, traduzido aqui como stakeholders, são stakeholders que possuem interface direta com o sistema, enquanto que stakeholders são organizações ou “atividade funcional” (tradução livre de “functional activity”) que possuem poder de decisão.

O desenvolvimento simultâneo do produto e dos processos é conseguido por meio do envolvimento dos stakeholders em um time de trabalho multidisciplinar e integrado – IPT (do inglês Integrated Product Team), cujos membros possuem poder de decisão relativo aos stakeholders que representam.

2.8.2.3 Planejamento Antecipado e Contínuo do Ciclo de Vida do Produto

O planejamento antecipado é conseguido com o envolvimento do time multidisciplinar – IPT que representam todos os aspectos do ciclo de vida do produto.

2.8.2.4 Identificação Proativa de Riscos e Gerenciamento de Risco

O envolvimento do time multidisciplinar tem como objetivo, desde as fases iniciais do projeto, de levantar, manter e gerenciar o acompanhamento de possíveis riscos ao projeto.

A identificação antecipada de possíveis problemas possibilita que o design do

produto incorpore a prevenção de problemas.

Várias técnicas podem ser usadas para análise e prevenção de problemas entre elas:

Redução da Variabilidade de Processo (VR) :
Origem da Causa e Ações Corretivas de Laço Fechado; · Design Robusto;
Método Taguchi;
Design Experimental (DOE) (tradução livre de “Design of Experiments”); · “Six Sigma”;
Controle de Processo Estatístico;

2.8.2.5 Maior flexibilidade em Contratos com Fornecedores.

O DOD enfatiza que IPPD é uma abordagem de gerenciamento e não apenas um conjunto de regras a serem seguidas, nesse sentido, contratos com os fornecedores devem permitir maior flexibilidade, ao incentivar a performance final do produto ou serviço ao invés do processo.

É justamente no processo de aquisição, o IPPD mostra seu maior potencial ao minimizar riscos e custos nas fases iniciais que são mais flexíveis, particularmente a Fases 0 e I que serão apresentadas na seção 2.8.3.

2.8.3 Implantação do IPPD

Embora o Manual de IPPD do DOD tem uma visão de cliente, voltado ao processo de aquisição, muitas da práticas e abordagens são tratadas de forma a servir de material para esse estudo.

O processo de aquisição de acordo com o DOD possui cinco estágios divididos por marcos de decisão. Os cinco estágios são:

Fase 0: Exploração de Conceito;
Fase I: Definição do Programa e Redução de Risco;
Fase II: Desenvolvimento de Engenharia e de Manufatura; · Fase III: Produção, Lançamento e Suporte Operacional;
Descarte.

De acordo com o Manual IPPD do DOD os primeiros passos para implantação do IPPD são:

Identificação das atividades – estudos, design, custo, performance, alternativas, fabricação etc.;
Identificação dos stakeholders – envolvidos diretamente em cada processo ou atividade, e incluindo os outros stakeholders governamentais, de suporte, logística, contrato etc.
Determinação do Envolvimento Contratual – o grau de envolvimento pode variar de consultoria informal, fornecimento de soluções ou até a completa responsabilidade;
Definição da Estrutura do Projeto – ou Estrutura da Divisão de Trabalho (WBS) identifica hardware, software, serviços, dados e infraestrutura e é a base para formar o Time Multidisciplinar Integrado (IPT);

Definição das Responsabilidades e Objetivos – após identificar o IPT é importante identificar os objetivos individuais e coletivo, nível de poder e métricas;
Treinamento dos Princípios do IPPD – treinamento contínuo dos participantes em todos os níveis;
Integração e co-localização do IPT – condição chave para aumentar a colaboração e troca de informação entre participantes do IPT é acomodação dos participantes em um mesmo ambiente;
Suporte à Comunicação – outro condição chave para a implantação é a troca de informação por meio de sistemas de informação que possibilitam a troca de arquivos e trabalho cooperativo. O suporte a comunicação envolve também a utilização de protocolos seguros de interface entre as diferentes ferramentas dos membros do IPT;
Definição de Métricas para o Projeto – padrões de medidas formam a base para aplicação de análises estatísticas do IPPD. As métricas são importantes para traçar metas e acompanhar os processos como: custo, cronograma, performance, entre outros.
Arquivamento de Processos, Atividades e Decisões – o arquivamento dos processos e acessibilidade aos stakeholders é importante ferramenta de análise para melhoria dos processos, para substituição de pessoal e tomada de decisões;

2.8.4 Exploração de Conceito – Fase 0

De forma ampla, o IPPD os objetivos da fase Exploração de Conceitos são:

Fazer estudos de conceitos para investigar diferentes soluções; 2. Avaliar os diferentes conceitos propostos;
Executar estudos comparativos;
Definir requisitos para os conceitos preferidos.

Durante a fase conceitual, são definidos aspectos técnicos e programáticos que irão influenciar todo o projeto, principalmente como os processos darão suporte aos princípios chaves do IPPD listados na seção 2.8.2.

Definição de Requisitos:

o Declaração das necessidades da missão; o Escolha de conceitos preferidos;

Definição dos Requisitos do Sistema:

o Análise dos conceitos escolhidos: análise das alternativas considerando performance, custo, cronograma e risco;

o Gerenciamento de risco: Identificação proativa de risco;

o Modelagem e simulação;

o Definição do Documento de Requisitos Operacionais (ORD)35 36 do nível de sistema;

o Após a definição do nível superior, continua para os níveis abaixo na hierarquia de sistema;

Definição do Programa:

o Definição de cronograma; o Plano integral;

o Estratégia de compra; o Identificação de riscos;

o Estimativas de custo do Custo do Ciclo de Vida (LCC); o Planejamento:

Planejamento das atividades de engenharia;
Planejamento da atividades de suporte, manufatura;
Preparação do Plano Diretor de Teste e Avaliação (TEMP);
Preparação do Plano Diretor Integrado – o plano do “como se faz”;
Contratação de pessoal;

35 O Documento de Requisitos Operacionais – ORD deve conter o mínimo número de requisitos necessários, e deve ser escrito em termos de funções do sistema sem as restrições de design de acordo com o DOD em oposição ao Especificação de Requisitos de Performance, onde são incluídos todos os requisitos (DOD,1998).

36 Apesar de o IPPD desenvolver todo os processos do ciclo de vida, não há mecanismos na fase de concepção para capturar requisitos não operacionais.

2.8.5 Definição do Programa e Redução de Risco – Fase I

Nesta fase são investigados os conceitos escolhidos na fase anterior bem como também analisados os riscos associados, com o objetivo de refinar os requisitos do programa para iniciar o processo de seleção do fornecedor. Basicamente há duas formas de seleção: fornecedor único ou em um ambiente competitivo.

Uma vez feito o contrato de fornecimento, cliente e fornecedor devem discutir os planos de execução do contrato do ponto de vista escopo de trabalho, cronograma e recursos.

Dado que o objetivo de ambos é o entendimento mútuo, é importante

identificar:

Riscos associados; · Elementos críticos;
Definição do Time Integrado do Produto (IPT) para prover a baseline.

2.9 Engenharia Simultânea

O objetivo desta seção é mostrar os conceitos básico da Engenharia

Simultânea e sua evolução.

2.9.1 Introdução

A Engenharia Simultânea foi concebida como um importante conceito na

década de 80 e tem sido extensivamente praticada desde então em várias formas e sob vários nomes. Embora o termo original em inglês “Concurrent Engineering” (CE) não seja mais frequentemente utilizado, seus conceitos e sua importância cresceram nos últimos anos e se transformaram em pré-condições para se trabalhar em projetos complexos e dinâmicos (Stjepandićet al,2015).

Numa definição mais moderna “Engenharia Simultânea é um enfoque compreensivo

e sistemático ao design concorrente, integrado no desenvolvimento de produtos complexos e seus processos relacionados, incluindo mercado, fabricação, logística, vendas, suporte ao cliente e descarte. Seus objetivos são alta produtividade e baixo

100

custo ao reduzir o tempo de desenvolvimento e o tempo de entrega” (STJEPANDIĆet al,2015).

Engenharia Simultânea não é um método e nem uma ferramenta, mas uma estratégia que traz benefícios de longo prazo quando aplicada corretamente (STJEPANDIĆet al,2015).

Ainda segundo Stjepandić et al (2015), a implementação de Engenharia Simultânea é um processo longo que demanda habilidade organizacional e técnica difícil de ser adquirida. A mudança da forma sequencial para a forma paralela de desenvolvimento necessita muito mais interação e aumenta o fluxo de informação entre as pessoas

Nos anos 80 e 90, Engenharia Simultânea, tinha o foco em antecipar o envolvimento dos processos subsequentes. Várias abordagens posteriormente surgiram com os conceitos de CE, como “Design para Fabricação” , “Design para Montagem” e “Design Para”.

Figura 2.24 – Duração do Desenvolvimento Enfoque Tradicional x Engenharia Simultânea

Fonte: Adaptado de INCOSE (2006)

O envolvimento dos stakeholders, como os Fabricantes Originais dos Equipamentos (OEM) (tradução livre para Original Equipment Manufacturer) o quanto antes também é parte da abordagem “Open Innovation” com o objetivo de reduzir os desperdícios.

Engenharia Simultânea tem basicamente 3 elementos:

Envolvimento antecipado dos stakeholders;

101

Abordagem de Equipe Integrada;
Desenvolvimento simultâneo das diferentes fases do produto.

O desejo de envolvimento de múltiplas considerações do ciclo de vida

necessita de uma integração maior dos times multidisciplinares muitas vezes espalhados geograficamente fez surgir o conceito de “Engenharia Colaborativa” (CE), cuja definição segue abaixo:

“Engenharia Colaborativa” (CE) é uma abordagem sistemática para controlar o ciclo de vida, custo, qualidade, e tempo de lançamento durante desenvolvimento de produto por meio do desenvolvimento concorrente de produto e seus processos em resposta as expectativas dos clientes, quando decisões garantem as entradas e sua avaliação de todo as funções do ciclo de vida, incluindo os fornecedores, suportado pela tecnologia da informação onde necessário” (WILLAERTA,1998).

Note que o Envolvimento Antecipado de Fornecedor (ESI) (tradução livre de “Early Supplier Involvement”) durante o processo de desenvolvimento é um dos elementos básicos da Engenharia Colaborativa, ao atribuir maior responsabilidade aos fornecedores durante as fases iniciais mas já estava presente na Engenharia Simultânea como consequência do envolvimento integrado dos stakeholders.

Embora o Envolvimento Antecipado de Fornecedor possa ter benefícios em potencial, há também impactos negativos que podem existir como incertezas tecnológicas, baixa confiança entre as partes, comunicação e coordenação pobre (MCIVOR;HUMPHREYS,2004). Fatores como esses fazem com que a relação de colaboração ainda seja motivo de debate pois envolve relações sociais e de comportamento humano conforme observa Stjepandićet al (2015).

2.9.2 Implantação de Engenharia Simultânea

De acordo com Syan e Menon (1994) há quatro classes fundamentais de apoio necessário à implantação Engenharia Simultânea:

Iniciadores;
Suporte Computacional;
Compartilhamento de dados;

102

Métodos.

2.9.2.1 Iniciadores

Os iniciadores fundamentais de implantação da abordagem de Engenharia Simultânea em um projeto são: trabalho em equipe e apoio organizacional.

Trabalho em Equipe:

Trabalho em equipe é a base do suporte a Engenharia Simultânea. Para atingir esse objetivo é importante que sejam observados alguns fatores: a formação e o entrosamento da equipe. A equipe por sua vez deve ser multidisciplinar e ter representatividade dos vários stakeholders dos processos do ciclo de vida (SYAN;MENON,1994). A equipe é uma força tarefa formada por representantes dos departamentos: desenvolvimento, manufatura, vendas, compras, financeiro, especialistas em ferramentas entre outros, e deve estar localizada em um mesmo ambiente para que propicie reuniões presenciais e troca de informação de forma eficaz.

Apoio Organizacional:

Mudança cultural para trabalho em equipe necessita apoio gerencial de cima. Sem envolvimento do alto comando da organização não se criam as condições de abertura e troca de informação.

A mudança deve ocorrer gradualmente em etapas com a ênfase na mudança cultura da organização. A Figura 2.25 mostra o processo de implementação de engenharia simultânea por projeto dentro de uma organização.

103

Figura 2.25 – Processo de Implementação Gradual de Engenharia Simultânea

Fonte: Adaptado de Syan e Menon (1994)

Barreiras Para Engenharia Simultânea:

Embora seja evidente os ganhos na adoção dos princípios da Engenharia

Simultânea, muitas organizações ainda possuem uma relutância natural, já que a mudança é considera muito radical para organizações acostumadas com o processo sequencial (MADDUX;SOUDER,2012).

Em Maddux e Souder (2012), são apontados dois tipos de barreiras para

implantação da Engenharia Simultânea: Organizacional e Técnica. As barreiras organizacionais são relacionadas a gerenciamento, políticas, comportamento da equipe, riscos etc. As barreiras técnicas estão relacionadas as falta de suporte e know-how (MADDUX;SOUDER,2012).

As barreiras organizacionais são as mais difíceis de serem transpassadas. Isso porque envolve relações complexas, como hierarquia, cultura, estilo e propensão a risco. Maddux e Souder (2012) lista 7 barreiras comum para a implantação da Engenharia Simultânea:

Falta de suporte do alto gerenciamento – a mudança deve começar de cima para ser aceita;
Clima organizacional inadequado – falta de atmosfera de abertura e confiança necessários para grande demanda de troca de informação;

104

Protecionismo dos Gerentes Funcionais – insegurança e medo dos gerentes pode suprimir esforços;
Recompensa inadequada – recompensa focada no departamento ao invés da performance organizacional;
Falta de envolvimento do cliente no design – o cliente/usuário conhece melhor que ninguém as suas necessidades;
Falta de envolvimento do fornecedor no design – maior envolvimento dos fornecedores e como parte da equipe de design ;
Medo de perda de criatividade – conflitos entre a liberdade de criatividade dos projetistas com a grande quantidade de requisitos imposta pelos clientes.

2.9.2.2 Suporte Computacional

O processo de desenvolvimento deve ter amplo suporte de ferramentas computacionais de design e simulação. O uso de ferramentas tridimensionais de design CAD podem servir de base para as ferramentas de modelagem e simulações como análise de elementos finitos entre outras

Não apenas o produto, mas os processos do ciclo de vida podem ser

simulados com uso dos modelos (SYAN;MENON,1994).

Suporte computacional pode ser divido em duas classes de acordo com Syan e Menon (1994):

Aplicações de engenharia e gerenciamento de processos;
Aplicações relacionadas a tecnologia da informação para troca de dados entre softwares em localidades diferentes.

Aplicações voltadas para engenharia envolvem software de apoio a design como CAD/CAM e CAE com habilidades de modelagem tridimensional incluindo características físicas simuladas como peso, centro de massa, resistência, rigidez, entre outras.

Modelagem de sólidos possibilita a planejamento dos processos de produção, integração etc.

Já as aplicações relacionadas a tecnologia da informação, de acordo com Stjepandićet al (2015), para trabalhar com eficiência em um ambiente amplo,

105

distribuído e colaborativo as equipes integradas de engenharia simultânea necessitam de sistemas de gerenciamento de informação baseados em arquitetura orientada a serviço.

Dado que um dos objetivos da Engenharia Simultânea é garantir que nenhuma

erro de design não avance sem ser detectado, o processo integrado de design deve ter 4 características essenciais segundo Stjepandićet al (2015):

Compartilhamento de informação – Cada membro da equipe necessita ter acesso a todas as ferramentas da organização;
Controle de configuração – Para garantir que o trabalho cooperativo funcione eficientemente é necessário que os desenvolvedores tenham acesso a informação de projeto atualizada interativamente;
Análise e Otimização – Os processos de engenharia devem permitir análise e optimização, isso inclui identificação de requisitos conflitantes e alertas e restrições resolvidas;
Registro e documentação – Todo o processo de design deve ser registrado e documentado para futura referência.

Para atender essa demanda de integração de informação é necessário que a

organização invista em um Sistema de Gerenciamento de Informação com as

seguintes características desejadas:

Versatilidade – para se adaptar as necessidades da organização; 2. Base de Dados – acesso ao base de dados de conhecimento da

organização sobre os processos dos ciclo de vida;

Inteligente e seguro – a informação certa deve ser facilmente acessível e específica para cada usuário;
Compatibilidade – A informação deve ser capaz de fazer interface com as ferramentas utilizadas pelos usuários;
Rastreabilidade Automática – O sistema deve ser capaz de correlacionar os impactos de alterações globalmente;
Ajuste e aprovação manual – Qualquer automatismo deve possibilitar intervenção humana;
Refinamento progressivo – O sistema deve permitir o refinamento progressivo do design de produto e processos;
Prototipagem rápida e teste – O sistema deve permitir prototipagem e teste como preparativo para produção.

106

2.9.2.3 Técnicas de Engenharia Simultânea

Um dos maiores benefícios da aplicação da Engenharia Simultânea é a de capturar restrições impostas pelos processos do ciclo de vida o mais cedo possível no estágio de desenvolvimento e assim evoluir o design. Para isso métodos e técnicas são utilizadas para capturar requisitos nas fases iniciais de desenvolvimento (SYAN;MENON,1994):

Matriz Funcional de Qualidade – QFD;
Design Experimental (DOE) (tradução livre de “Design of Experiments”); · Método Taguchi;
Gerenciamento da Qualidade Total (TQM); · Design para Manufatura (DFM);
Design para Montagem (DFA);
Programa de Melhorias Contínuas;
Ferramentas de Design de Avaliação de Maturidade; · Ferramentas de Avaliação de Custos;
FMEA (STJEPANDIĆet al,2015). Desdobramento Funcional de Qualidade – QFD:

Desdobramento Funcional de Qualidade – QFD (tradução livre de “Quality Functional Deployment”) é um método que ajuda a transformar necessidades dos clientes em característica e ou requisitos de produto ou serviço. A matriz QFD ajuda a correlacionar uma grande quantidade de dados, e permite quantificar a satisfação do cliente, conforme pode ser visto na Figura 2.26.

107

Figura 2.26 – Desdobramento Funcional de Qualidade “House of Quality”

Fonte: Adaptado de PM BOOKS (2016)

2.9.2.4 Compartilhamento de dados

Devido a alta quantidade de informação a ser trocada como desenhos, e arquivo de dados em formas diferentes, rede segura é pré-requisito para as prática de CE.

Um estudo conduzido pelo Instituto de Análise de Defesa (IDA) USA, identifica as seguintes medidas para atingir CE com sucesso:

Suporte gerencial e experiente;

108

Mudança são feitas para substituir práticas anteriores e não adicional; · Percepção comum dentro que das novas práticas na organização;
Os times dever ser multidisciplinares durante o desenvolvimento; · Relaxar as políticas que inibam a mudança de design
prover autoridade e responsabilidade aos times de projeto;

Lições aprendidas de características chaves para implementação com sucesso de CE:

Equipes multidisciplinares;
Comunicação coordenada entre os disciplinas e organizações; · Gerenciamento de qualidade;
Simulações computacional de produto e seus processos;
Integração de ferramentas computacionais e de base de dados; · Programa de treinamento de pessoal em todos os níveis
Colaborador deve ter a atitude de “proprietário” do processo que esta envolvido;
Comprometimento contínuo e permanente com a melhora

2.10 Análise Estruturada e o Framework de Visão Total

Desde o aparecimento do Desenvolvimento Integrado a indústria tem

trabalhado com foco no esforço de desenvolvimento do produto, seu ciclo de vida, e a organização dos processo de ciclo de vida.

Nessa abordagem os requisitos do produto são as entradas para organização desenvolvedora, e para atender aos requisitos, a organização desenvolve não apenas o produto, mas os processos do ciclo de vida e se organiza para se adaptar a esses processos. Todo esse esforço de desenvolvimento resulta em um conjunto de atributos do produto, do ciclo de vida e da organização.

O conjunto desses atributos, tais como: qualidade do produto, tempo para ser

lançado e sua produtividade (que vai determinar seu custo por exemplo) afetam a percepção do usuário. Dessa forma o conjunto desses atributos, apontam que os esforços de desenvolvimento não estão apenas no produto mas, também no seu ciclo de vida e na organização desenvolvedora.

109

Loureiro (1999), argumenta que engenharia de sistemas, como definida na norma IEEE-std-1220 de 1994, é “uma abordagem colaborativa, interdisciplinar para derivar, evoluir e verificar uma solução de sistema equilibrada do ciclo de vida que satisfaça as expectativas dos usuários e atenda a aceitabilidade pública”, e prossegue afirmando que a norma é focada no desenvolvimento do produto, onde são aplicados os Processos de Engenharia de Sistemas. O ciclo de vida do produto é analisado apenas pelo processo Análise de Requisitos, enquanto a organização desenvolvedora não há processo algum aplicado.

Loureiro (1999) vai além e propõe um framework para o desenvolvimento

produtos complexos no qual, aplicando análise estruturada concomitantemente com uma abordagem da engenharia simultânea e com os métodos e processos da engenharia de sistemas, resultando em um framework de visão total para produto, seus processos do ciclo de vida e as organizações que os realizam (LOUREIRO,1999).

Mesmo abordagens mais modernas como a Engenharia Simultânea fundamentada em princípios organizacionais e práticas que cobrem todo o escopo do ciclo de vida não aborda por completo as três dimensões do desenvolvimento que o Framework de Visão Total (tradução livre de “Total View Framework”) cobre:

Dimensão de Análise: Análise de Requisitos, Funcional e Física;

Dimensão da Estrutura Hierárquica: Sistema, Produtos, Subsistema, elementos, unidades…;
Dimensão de Integração: Produto, Ciclo de Vida e Organização.

110

Figura 2.27 – As Três Dimensões do Framework de Visão Total

Fonte: Adaptado de Loureiro (1999)

Em resumo, no Framework de Visão Total aplica-se o processos de

Engenharia de Sistemas para a engenhar simultaneamente o produto, os processos e as organizações desenvolvedoras dos processos, para cada nível da hierarquia do produto.

No Framework de Visão Total o conceito de sistemas, conforme visto pelas

normas EIA-632 (ANSI,2003) e IEEE-Std-1220 (2005) de Engenharia de sistemas, é expandido para também abranger as organizações desenvolvedoras dos processos do ciclo de vida, conforme a Figura 2.28.

111

Figura 2.28 – Comparação Entre o Escopo do Sistema da Norma EIA-632 (ANSI,1997) em Relação ao Framework de Visão Total.

Fonte: Adaptado de Loureiro (1999)

Ao integrar as 3 dimensões, o framework de modelagem da Visão Total de 1999 expõe algumas redundâncias principalmente no que concerne a dimensão de integração, dado que processos do ciclo de vida do produto, são na prática, funções das organizações que as realizam (LOUREIRO, 2010).

Por outro lado, a própria norma IEEE-Std-1220:2005 considera os processos do ciclo de vida como “building blocks” do sistema e aplicando o Processo de Engenharia de Sistemas – SEP também aos processos do ciclo de vida.

Dessa forma uma simplificação do Framework de Visão Total é sugerida por

Loureiro como mostra na Figura 2.29, onde a camada de processos do ciclo de vida do produto, é analisada pelo método estruturado proposto pelo autor durante a análise funcional dos elementos da organização. Consequentemente o framework proposto por Loureiro (2010), integra somente os elementos do sistema, i.e., elementos do produto e elementos de organização (LOUREIRO,2010).

112

O método de Loureiro evolui também na dimensão de análise onde é destacado a análise de stakeholder precedendo a análise de requisitos, conforme a Figura 2.30.

Figura 2.29 – As três dimensões da Evolução do Framework de Visão Total

Fonte: Adaptado de Loureiro (2010)

Figura 2.30 – A Evolução do Método Estruturado de Engenharia Simultânea

Fonte: Adaptado de Loureiro (2010)

113

2.10.1 Dimensão de Análise

Na dimensão de análise estão os processo de análise de requisitos, análise funcional e de análise física. Estes processos de análise usam basicamente os métodos e ferramentas de Análise Estruturada com algumas adaptações. Esses métodos de análise estruturada são suportados por técnicas de modelagem.

Como resultado dos processos de análise, requisitos e atributos são identificados e seus relacionamentos capturados (Loureiro,1999).

2.10.1.1 Modelagem

As técnicas de modelagem utilizadas por Loureiro (1999) são a já bem estabelecidas técnicas de Análise Estrutural de Yourdon (1989) e Jacobson (1994) com a diferença de que são aplicadas simultaneamente ao produto, seus processos de ciclo de vida e as organizações desenvolvedoras.

A Tabela 2.4 mostra as propostas de abordagem e notação para modelagem para a dimensão de análise (vertical) e para a dimensão de integração (horizontal).

Tabela 2.4 – Proposta de abordagem e notação para modelagem

Processos de Análises Produto Processo Organização

Requisitos

Funcional

Físico

Abordagem:

Notação:

Abordagem:

Notação:

Abordagem:

Notação:

Loureiro DFD adaptado à

Diagrama de Stakeholders de Produto (Figura 2.31) Yourdon DFD, STD, ERD, Event List

Hatley/Pirbhai DFD, FBD, Gráfico

Estruturado, Desenhos CAD

Loureiro IDEF0 adaptado à

Diagrama de Stakeholders de Processo (Figura 2.32) SADT/Marca

IDEF0, BD

SADT/Marca

IDEF0, BD

Loureiro UCD adaptado à

Diagrama de Stakeholders de Organização (Figura 2.33) Jacobson/UML

UCD, SQD, COD

UML Adaptado

UCD, PD, CPD, CD, DPD, SCD, ACD

Fonte: Adaptado de Loureiro (1999)

114

2.10.1.2 Modelagem de Produto

Para modelagem de requisitos de produto, Loureiro propõe Diagrama de Fluxo de Dados – DFD adaptado, no qual o diagrama de contexto onde o centro fica missão e objetivo e é cercado por retângulos onde ficam os stakeholders que interagem com o produto. As setas mostram suas preocupações em relação ao produto, conforme modelo da Figura 2.31.

Para modelagem funcional de produto a abordagem é a da análise estruturada de Yourdon (1989): Diagramas de Fluxo de Dados – DFD, Diagramas de Transição de Dados – STD, Diagramas de Relacionamento de Entidades – ERD e Lista de Eventos são amplamente utilizados.

Para modelagem física do produto a abordagem sugerida é a de Hartley e Pirbhai: Diagramas de Fluxo de Dados – DFD, Diagramas de Bloco Funcional – FBD, diagramas estruturados e desenhos CAD.

Figura 2.31 – Modelo de DFD adaptado para Análise de Requisitos de Produto

Fonte: Adaptado de Loureiro (1999)

2.10.1.3 Modelagem de Processo

Para modelagem de requisitos de processo, Loureiro propõe IDEF0 adaptado, no qual para cada stakeholder de entrada, de controle, de saída e de

115

mecanismo mostram suas preocupações em relação ao processo, conforme modelo da Figura 2.32.

Para modelagem funcional e física de processo a abordagem é a de Análise Estruturada e Técnicas de Design de Marca e McGowan, com Diagramas IDEF0, Diagramas de Comportamento – BD37.

Figura 2.32 – Modelo de IDEF0 adaptado para Análise de Requisitos de Processo

Fonte: Adaptado de Loureiro (1999)

2.10.1.4 Modelagem de Organização

Para modelagem de organização, Loureiro utiliza as ferramentas de UML de

modelagem, com adaptação apenas para a modelagem de requisitos de organização onde o diagrama de Use Case adaptado para capturar apenas os stakeholders e suas preocupações conforme exemplo da Figura 2.33.

37 O uso de diagramas IDEF0 para modelagem funcional de processos, destacará intrinsicamente a decomposição física do processo por meio dos mecanismos

116

Para modelagem funcional Loureiro destaca a Diagrama de Sequência – SQD e Diagrama de Colaboração – COD e para modelagem físico, os destaques são para os digramas de pacotes – PD, de atividade – ACD, de componente – CPD e transição de estado – SCD.

Figura 2.33 – Exemplo de Diagrama Use Case adaptado para Análise de Requisitos de Organização

Fonte: Loureiro (1999)

2.10.2 Dimensão da Estrutura hierárquica

A dimensão da estrutura hierárquica define a complexidade de como o sistema é estruturado. Sistemas são decompostos em outro sistemas formando uma pirâmide hierárquica dessa decomposição. O framework de visão total considera todos os níveis da decomposição hierárquica do sistema.

2.10.3 Dimensão de Integração

A dimensão de integração define os elementos a serem integrados ao sistema a ser desenvolvido. Os elementos de sistema, i.e., os elementos de integração são os elementos de produto, e os elementos de organizações que executam os ciclos de vidas (LOUREIRO,2010).

117

Embora os processos do ciclo de vida não fazem parte dos elementos a serem integrados ao sistema, de acordo com essa visão, os processos do ciclo de vida são analisados na dimensão de análise (veja seção 2.10.1).

Dessa forma, além do produto de interesse (end product) a organização irá

derivar produtos de interesse para o processos operacionais assim como são considerados produtos de interesse as organizações que executam esses processos.

Por outro lado, os processos não-operacionais do ciclo de vida, irão derivar produtos de apoio (enabling products) que também deverão ser desenvolvidos, bem como as organizações que executam esses processos.

Processos não-operacionais do ciclo de vida, i.e. desenvolver, produzir, testar, distribuir etc, e suas organizações desenvolvedoras são implementadas pelo uso de produtos de apoio (enabling products).

Na Figura 2.28 as caixas em preto representam os elementos dentro do esforço de desenvolvimento. Note que no Total View Framework o esforço de desenvolvimento é muito mais abrangente comparado como o pregado pela norma EIA-632 (ANSI,2003).

Dessa forma Framework de Visão Total pretende identificar os atributos, não apenas do produto, mas também de seus processos do ciclo de vida e de suas organizações e as relações entre esses atributos. Esses atributos são identificados por meio dos quatro processos de análise de engenharia de sistemas (Loureiro,2010):

Análise de Stakeholder; · Análise de Requisitos; · Análise Funcional;
Análise Física.

118

2.10.4 Requisitos e Atributos

De acordo com Loureiro, o modelo proposto de processo de desenvolvimento deve acontecer em dois domínios: um domínio de problema e um domínio solução.

Os stakeholders trabalham no domínio do problema, com requisitos que descrevem suas necessidades, desejos, vontades, ao passo que o “sistema”38 trabalha no domínico da solução.

Requisitos e atributos descrevem característica de um sistema no domínio do problema e no domínio da solução respectivamente e servem de linguagem para descrever um sistema entre duas entidades: os stakeholders e a organização desenvolvedora conforme representação da

Figura 2.34 – Requisitos e Atributos de um Sistema

Fonte: Adaptado de Loureiro (1999)

Em resumo, de acordo com Loureiro o sistema é a solução balanceada quando considerado os atributos do produto, dos processos e da organização desenvolvedora. Os atributos permitem aos stakeholders medir o quanto seus requisitos foram atendidos pela solução de sistema. E quanto mais cedo as relações entre requisitos e atributos e entre os atributos, forem identificadas, melhor será a visão de quanto é necessário para evoluir o sistema.

Devido a grande quantidade de relacionamentos requisitos/atributos e entre atributos possíveis em um produto complexo, é muito fácil desconsidera-los e

38 O sistema é a resposta em termos de atributos e que atende aos requisitos

119

somente perceber tardiamente durante o ciclo de vida do produto onde o custo de mudança é muito maior.

Loureiro propõe ainda que os conceitos de requisitos e atributos seja unificados como uma linguagem comum para descrever produtos, processos e organização.

2.10.5 Processos Estruturados de Engenharia Simultânea

Nesta seção será descrito o processo estruturado de engenharia simultânea

descrito por Loureiro (1999), incluindo as lições aprendidas em 2010 (Loureiro,2010), e aplicado ao Framework de Visão Total.

2.10.5.1 Análise de Stakeholder

A análise de stakeholder é dividida em duas partes: stakeholders de produto e stakeholders de organização.

Os stakeholders de produto são as pessoas ou organizações que afetam ou

são afetadas diretamente pelos atributos do produto final e de seus processos do ciclo de vida (Loureiro,2010). Para determinar quem são os stakeholders de produto, cada cenário dos processos do ciclo de vida, stakeholders de produto são as pessoas ou organizações que são as fontes de entrada, destino das saídas e fornecedores de mecanismos e controles.

Para determinar os stakeholders de organização, para cada ciclo de vida dentro do escopo do esforço de desenvolvimento, stakeholders de organização são pessoas ou organizações, fora da organização desenvolvedora que podem ter algum relação com o negócio da organização desenvolvedora.

2.10.5.2 Análise de Requisito

A o objetivo da análise de requisitos é transformar as necessidades e requisitos dos stakeholders em requisitos de técnicos do sistema. Requisitos de stakeholders podem não ser escritos de forma objetiva ou em termos verificáveis.

120

Ao transformar requisitos de stakeholders em requisitos técnicos, serão assumidos pressupostos e condições, que devem ser rastreadas aos requisitos técnicos.

Requisitos técnicos, juntamente com pressupostos e condições são então

compilados para os documentos de requisitos do sistema.

Os requisitos do sistema são satisfeitos não apenas pela solução dos elementos produtos mas também pelo elementos da organização.

2.10.5.3 Análise de Funcional

A Análise funcional começa pela identificação dos sistemas externos e suas interfaces, que formam o ambiente ao qual o produto final esta inserido.

A análise também deve identificar o escopo das funções do produto final.

Para determinação das fronteiras do sistema é necessário a modelagem do ambiente ao qual o sistema esta inserido. A modelagem é feita por meio dos diagramas DFD de contexto.

Os diagramas DFD de contexto são feitos a partir dos cenário relevantes do ciclo de vida, posicionando o sistema proposto no centro do diagrama, circundado por todos os possíveis stakeholders e sistemas externos que de alguma forma troquem informação matéria ou energia com o sistema proposto.

A Análise de cenário começa com uma descrição dos cenários relevantes.

Cenários relevantes são aqueles que possuem elementos diferentes no ambiente no qual o produto final esta inserido. Os cenários relevantes devem ser escolhidos de forma que contenham a totalidade dos elementos externos e suas circunstâncias.

Para cada cenário relevante, faz se a análise de contexto do sistema onde são levantados as circunstâncias.

Circunstância são variações no ambiente relacionados aos cenários. Essas

variações de ambiente ao qual o sistema esta inserido induzem estados e modos no sistema.

121

A partir dos diagramas são identificados os fluxos (informação, matéria e energia) que entram e saem do sistema.

Dependendo dos diferentes conjuntos de circunstâncias, o sistema irá executar um cenário dentro do ciclo de vida em um processo de ciclo de vida em modos diferentes.

Modos não se referem apenas às operações, mas também para a produção, testes, distribuição, manutenção, descarte.

Para cada modo, uma lista de eventos é preparado e funções essenciais são identificados. Em primeiro lugar para os modos normais ou esperados e, posteriormente, para os modos de manipulação de exceção.

Resumindo:

Cenários relevantes àAnálise de Contexto àCircunstâncias àModos àEventos

O conjunto de funções essenciais é concluída no primeiro nível de

decomposição funcional do sistema.

O comportamento do sistema em cada modo e para a transição de modo é analisada, sendo-lhes modos normais de manuseio ou exceção

Um caso especial de manipulação de exceção é a análise de risco. Circunstâncias, falhas de interface externas e qualquer mau funcionamento do sistema são potenciais fontes de perigo.

2.10.5.4 Análise de Implementação

O processo de implementação é essencialmente a solução física para a solução funcional previamente proposta no processo de Análise Funcional.

A partir da arquitetura funcional elementos, subsistema e componentes são

identificados onde são alocados as funções resultantes da arquitetura funcional, ao mesmo tempo que são identificados as interfaces entre os elementos propostos.

Elementos e Interfaces são então arranjados de forma a estabelecer uma

arquitetura física coerente e funcional que atenda aos requisitos.

122

3 Revisão Bibliográfica

O objetivo deste capítulo é mostrar como a literatura trata do desenvolvimento de GSE.

3.1 Sistemas de Apoio segundo a norma ISO/IEC15288:2008

Como um dos objetivos dessa seção é analisar a norma ISO/IEC15288:2008 sob a ótica do desenvolvimento de sistemas de apoio e mais especificamente de GSE, foram verificadas todas as ocorrências do termo “Enabling Systems” na norma ISO/IEC 15288:2008. No total foram identificas 49 ocorrências de “Enabling Systems” na norma ISO/IEC 15288:2008. A seguir será mostrado uma síntese da forma como os sistemas de apoio são tratados pela norma.

3.1.1 Visão Geral de Sistemas de Apoio

De acordo com a norma ISO/IEC 15288:2008 um determinado sistema de interesse necessita de sistemas de apoio para percorrer seu ciclo de vida, como por exemplo: sistema de produção em massa, sistema de treinamento, e sistema de manutenção. O termo “sistemas de apoio” é usado para todo sistema que dá suporte ao sistema de interesse durante os estágios do ciclo de vida mas que não está diretamente relacionado com aos serviços fornecidos pelo sistema de interesse no ambiente operacional.

Porém a norma ISO/IEC15288:2008 admite que sistemas de apoio possam

contribuir indiretamente aos serviços fornecidos pelo sistema de interesse conforme pode ser observado no trecho a seguir:

“Os sistemas de apoio podem ser vistos como sistemas que contribuem indiretamente para os serviços prestados pelo sistema de interesse. As inter-relações entre o sistema de interesse e os sistemas de apoio podem ser bidirecionais ou uma relação unidirecional” (ISO / IEC 15288:2008, p.9, grifo do autor)

Segundo Halligan (2008), a definição de sistemas de apoio na ISO/IEC 15288:2008 (reproduzida logo abaixo) é inadequada ao utilizar a expressão “sistema que suporta o sistema de interesse durante seu ciclo de vida….” e ao

123

admitir que um sistema de apoio contribua diretamente às funções do sistema de interesse. Ainda segundo Halligan, somente o exemplo dado de que um sistema de apoio à produção, necessário para o estágio de produção do sistema de interesse esta correto (HALLIGAN,2008).

Essa confusão também é perceptível na Figura 3.1 que mostra as relações dos serviços entregues no ambiente operacional pelo sistema de interesse e os serviços entregues dos sistemas de apoio ao sistema de interesse, admitindo assim a contribuição indireta aos serviços entregues pelo sistema de interesse.

“Sistema de apoio: sistema que suporta um sistema de interesse durante seus estágios de ciclo de vida, mas que não necessariamente contribui diretamente para sua função durante a operação” (ISO / IEC 15288: 2008, p.4)

Figura 3.1 – Sistema de Interesse, seu Ambiente Operacional e os Sistemas de Apoio

Fonte: Adaptado de ISO/IEC 15288 (2008)

A norma ISO/IEC 15288:2008 não trata de forma isolada o desenvolvimento dos sistemas de apoio, devido à recursividade do processo de engenharia. Dessa forma os sistema de apoio são tratados pela norma como sistemas de interesse durante seu desenvolvimento e então são aplicados os processos do ciclo de vida do sistema. Adicionalmente, a norma indica o guia ISO/IEC TR

124

19760 que detalha a aplicação dos processos do ciclo de vida de sistema ao sistema de apoio e tratado na seção 3.1.2.

3.1.2 Desenvolvimento de Sistemas de Apoio

O guia de aplicação da norma ISO/IEC 15288 – ISO/IEC TR 19760 traz uma seção intitulada de “Definição e Realização de Sistemas de Apoio”, que de forma recorrente simplesmente aplica os processos de engenharia da norma ISO/IEC 15288 ao Sistema de Apoio para o seu desenvolvimento da mesma forma como é aplicado ao sistema de interesse, conforme destacado na Figura 3.2.

Um ponto a ser notado é que no processo de realização do sistema de apoio da Figura 3.2 é possível notar que os requisitos do sistema de apoio são originados a partir do processo de arquitetura de design (ou processo de implementação) do sistema de interesse no nível na estrutura hierárquica do sistema também destacado na Figura 3.2.

Figura 3.2 – Realização de Sistema de Apoio

Fonte: Adaptado de ISO/IEC TR 19760 (2003)

125

No Processo de Arquitetura de Design da norma ISO/IEC 15288, brevemente descrito na Seção 2.4.5.4.3 desta dissertação, possui como tarefa “analisar e avaliar a arquitetura”, na qual uma das notas de aplicação aponta para “garantir que as restrições dos sistemas de apoio sejam levadas em conta no design (do sistema de interesse)”. Não há indicação no Processo de Arquitetura de Design de saída relativo à requisitos para o Sistema de Apoio, como sugerido pelo processo de realização do sistema de apoio da Figura 3.2.

Por outro lado o processo de Definição de Requisitos dos Stakeholders da

norma ISO/IEC 15288, brevemente descrito na Seção 2.4.5.4.1 desta dissertação, trata de sistemas de apoio em suas atividades, mas apenas demandando requisitos aos sistemas de apoio como consequência da definição das restrições da solução de sistema com os decisões técnicas.

Outros processos tais como Processo Planejamento de Projeto (Seção 2.4.5.3.1), Processo de Implementação (Seção 2.4.5.4.4), Processo de Integração (Seção 2.4.5.4.5), Processo de Verificação (Seção 2.4.5.4.6), Processo de Transição (Seção 2.4.5.4.7) e Processo de Validação (Seção 2.4.5.4.8) também possuem diretivas para os sistemas de apoio.

Segundo a norma, durante um estágio do ciclo de vida, o sistema de apoio relevante e o sistema de interesse devem ser considerados em conjunto dado sua interdependência, e portanto deva ser considerado como um único sistema.

No processo de verificação, e mais especificamente durante o planejamento da verificação na Seção 2.4.5.4.6.1, a norma ressalta a possibilidade de requisitos provenientes de sistema de apoio serem demandados ao sistema de interesse, porém esse processo não especifica nenhuma saída relacionado à requisitos de sistema. Também não se observa no processo de Análise de Requisitos, na Seção 2.4.5.4.2, a preocupação com possíveis requisitos serem incorporados

126

devido à implementação dos estágios do ciclo de vida não operacionais do sistema.

3.2 Sistemas de Apoio segundo a NASA

No processo de engenharia da NASA os Sistemas Apoio aparecem já na primeira passada no Motor ES (“SE Engine”) apresentado na Seção 2.2.1, no nível imediatamente abaixo alto da hierarquia do sistema (nível 1).

Esse processo começa na fase A, conceitual (NASA,2007). ,

De forma recursiva a segunda rodada/passada do Motor ES da NASA, é feita no nível 1 em cada um dos produtos decompostos (do sistema de interesse), gerando o nível 3 e assim recursivamente

A cada rodada que o Motor ES é aplicado são esperados como saída:

Decomposição em produtos do nível abaixo (decomposição hierárquica);
Stakeholders do produto, incluindo novos stakeholders que podem aparecer;
Conceito de Operações para cada um dos produtos; d. Requisitos técnicos dos produtos;
Solução de projeto do produto (com detalhamento suficiente para o nível do produto);
Requisitos dos Produtos de Apoio que podem aparecer na arvore de produtos.

Observe que para cada Produto de Interesse que é decomposto, um ou mais Produtos de Apoio também podem ser necessários para os processos de realização do Produto de Interesse (NASA,2007).

O Processo de Definição da Solução de Design do Motor SE tem como uma de suas saídas gerar os requisitos dos sistemas de apoio para os stakeholders de implementação de produto final, conforme mostra a Figura 3.3 e reproduzido no trecho logo abaixo:

“Os requisitos do produto de apoio são documentados como parte do pacote de dados técnicos para o Processo de Definição da Solução de Design” (NASA,2007).

127

De fato uma das tarefas importantes do processo de Definição da Solução de Design é “Identificar os sistemas de apoio”, ou seja produtos ou serviços necessários para dar suporte ao produto final nos seus ciclos de vida.

Figura 3.3 – Processo de Definição da Solução de Design da NASA

Fonte: Adaptado de NASA (2007)

Da mesma forma como a norma ISO/IEC 15288, o manual da NASA também considera produto final e produto de apoio interdependentes e portanto devem ser vistos como um único sistema. Com isso a organização desenvolvedora do produto final tem a responsabilidade de adquirir ou desenvolver os serviços dos produtos de apoio relevantes, conforme os trecho reproduzidos abaixo:

128

“Como o produto final e seus produtos de apoio são interdependentes, eles são vistos como um sistema. Assim, a responsabilidade do projeto se estende à responsabilidade pela aquisição de serviços dos produtos de apoio relevantes em cada fase do ciclo de vida.

[…]

Em seguida, devem ser estabelecidos compromissos na forma de contratos, acordos e / ou planos operacionais para garantir que os produtos de apoio devem estar disponíveis quando necessário para dar suporte às atividades das fase do ciclo de vida do produtos” (NASA,2007).

Na verdade, toda vez que se aplica o Motor ES a qualquer nível, sempre será decomposto em produtos de interesse e seus associados produtos apoio.

Neste trabalho, será enfatizado apenas os Produtos de Apoio do processo de

realização do processo de AIT do sistema para que não se saia dos objetivos gerais deste trabalho.

Para exercitarmos o Motor ES da NASA, tomemos como exemplo um satélite. Nesse exemplo iremos focar nos produtos de apoio e mostrar como o Motor ES é aplicado.

A Figura 3.4 mostra a hierarquia do sistema espacial do exemplo. Aplicando o Motor ES aos níveis superiores de forma recursiva, são gerados os produtos dos nível logo abaixo.

Observe que o Motor ES não somente gera os produtos logo abaixo, mas sim um gama saídas que permite o detalhamento do produto: requisitos, conceito de operações, stakeholders, entre outros.

Nesse exemplo, a partir do nível 2 é possível observar a aparição dos produto

de apoio: GSE-Satélite. O GSE-Satélite é conjunto de ferramentas necessários para a realização do Satélite, que é o produto de interesse. A Figura 3.4 também destaca em cores azuis outros produtos de interesse e em cor vinho os respectivo produtos de apoio.

129

Figura 3.4 – Hierarquia do Sistema:

Produtos finais a esquerda e seus correspondentes produtos de apoio para integração e testes.

Nível 1 Segmento Espacial

Nível 2 Satélite

Segmento Solo

GSE-

Satélite

Nível 3 PSS TTC AOCS

PAYLOA

GWC GSE-PSS GSE-TTC

GSE-

AOCS

GSE-PAYLOA

Nível 4 SAG PCU Bateria GSE-SAG GSE PCU GSE BAT

Deploy

Rig

SAS BATSIM

Nível 5

Fonte: Adaptado de NASA (2007)

Os esforços de desenvolvimento dos produto de apoio de um determinado

nível na escala hierárquica de sistema pode atender não apenas ao ciclo de vida do próprio nível, como também parte do ciclo de vida do produto imediatamente acima na hierarquia do sistema a partir do momento de sua integração. Essa afirmação é apenas a consequência da extrapolação da afirmação de que um determinado produto deva atender aos requisitos de seu ciclo de vida completo, ou seja a fase E – Operação do sistema em foco, tem início na integração do sistema imediatamente acima, conforme pode ser observado na Figura 3.5.

A Figura 3.5 também mostra o ciclo de vida do GSE do subsistema em relação a ciclo de vida do subsistema e em relação ao sistema.

Podemos observar também na Figura 3.5 as diferenças dos ciclos de vida de um subsistema e do GSE de um subsistema.

130

Figura 3.5 – Correlação do Ciclo de Vida de um Sistema, um subsistema e seu EGSE com destaque na fase E

Fonte: Baseado em NASA (2007)

Para exemplificar a afirmação acima, tomemos o subsistema PSS do satélite. O GSE do PSS deve atender as fases de teste do subsistema PSS mas também pode atender aos testes do PSS integrado no satélite, já que PSS integrado no satélite, ou seja em seu ambiente operacional, faz parte do estágio operacional do ciclo de vida do subsistema PSS.

Da análise acima pode-se concluir que para um determinado produto de interesse:

Os requisitos de um produto devem cobrir também os esforços de integração desse produto no nível acima.

Da mesma forma pode-se concluir que para o GSE do mesmo produto:

Os requisitos do GSE de um produto podem atender aos requisito de

teste e operação do produto durante o AIT;

Os esforços de integração do produto no nível acima, pode ou não fazer parte do escopo de desenvolvimento do GSE do produto, ou seja vai depender do WBS de sistema.

131

A conclusão 3 acima mostra que o WBS, que é definido nas fase A do ciclo de vida do sistema terá impacto nos esforços totais de desenvolvimento do sistema e de seus produtos.

Não há como definir regras para a divisão do WBS, e sim uma análise bem

detalhada, dos esforços de desenvolvimento em relação a forma como a organização desenvolvedora planeja fazer o desenvolvimento. O que é importante observar é que:

Para cada produto do PBS, uma análise detalhada de todo o ciclo de vida do produto e seus níveis imediatamente acima e imediatamente abaixo devem ser feito tendo em vista todos os esforços de integração;
Nessa análise dos ciclos de vidas dos produtos, sobreposições devem ser identificadas.
Para cada sobreposição a autoridade de sistema deve determinar e destacar no WBS, sem ambiguidades para que posteriormente a matriz de atribuições possa apontar com clareza o responsável pelo esforço de desenvolvimento;
Com o WBS definido, cabe aos responsáveis dos produtos identificar as interfaces e estabelecer em comum acordo uma matriz de interfaces entre os produtos (na árvore hierárquica) e seus GSEs, ao longo dos ciclos de vida.

132

4 Estado da Prática do Desenvolvimento de GSE

O objetivo deste capítulo é fazer uma análise do processo de desenvolvimento dos Equipamentos de Suporte em Solo (GSE) de alguns dos principais projetos espaciais no qual houve envolvimento brasileiro: programa CBERS 3&4, projeto SGDC e programa PMM.

4.1 Introdução

O objetivo desta análise é tentar mostrar o processo de desenvolvimento de GSE no contexto dos programas espaciais escolhidos para estudo.

O motivo da escolha desses projetos espaciais pode ser resumida em três pontos principais:

Projetos com participação brasileira e sobretudo participação efetiva e familiaridade do autor deste trabalho;
Projetos de grande envergadura no cenário espacial brasileiro; · Grande diferença entre os projetos com relação ao processo de

desenvolvimento do satélite e principalmente do GSE;

Os três fatores acima são importantes nessa análise pois seu conhecimento

balizará a proposta final deste trabalho apresentada no capítulo 5.

O programa CBERS foi escolhido por ser o principal programa de desenvolvimento de satélites do INPE e por ter uma documentação disponível e catalogada no sistema gerenciamento de documentos Windchill do INPE.

O programa PMM foi escolhido por ser um desenvolvimento completamente brasileiro e estar em uma fase de desenvolvimento interessante para este trabalho, com o modelo EM do satélite Amazonia-1 preste a iniciar o processo de AIT. Nesta fase estão em finalização os designs do EGSE e MGSE, o que será de grande valia para a discussão do Capítulo 7 onde será comparando os requisitos funcionais da solução atual do EGSE com uma solução proposta aplicando o processo do Capítulo 5.

133

Já o projeto SGDC foi escolhido por ter sido desenvolvido por organização não brasileira com 40 anos experiência em desenvolvimento de satélites e sistemas espaciais.

Para que seja possível a análise do GSE dos projetos espaciais escolhidos,

primeiramente será feita uma descrição técnica dos satélites e seus subsistemas em termos de requisitos técnicos, em seguida será feita uma descrição do ciclo de desenvolvimento do sistema de interesse, isto é, o satélite e seus subsistemas, e dos produtos de apoio, i.e., o GSE para AIT do satélite.

A análise apresentada é baseada em documentos disponíveis e em boa parte à experiência e conhecimento do autor nos projetos escolhidos. A experiência do autor contribui apenas no sentido de preencher lacunas de informação que não são facilmente encontradas nos documentos dos programas. Essas lacunas de informação ocorrem por diferentes razões dependendo do projeto:

Para o programa CBERS, a análise considerou dezenas de documentos oficiais disponível no sistema Windchill do INPE. Embora extensa, a documentação do CBERS não possui rastreabilidade conforme observado por Almeida (2011, p.136).

Outro ponto a ser considerado nessa análise é a falta de completude na documentação disponível. Essa falta de completude pode ocorrer por simples falta de exigência no projeto, omissão em virtude do “estado da arte” do INPE, ou porque o documento foi classificado como “reservado” e não é disponibilizado no sistema Windchill. A classificação de alguns desses documentos de “reservado”, ou seja, de distribuição restrita e mediante autorização do autor e/ou chefia é prevista no INPE, e por consequência dificulta a análise. (INPE, 1990). Cabe lembrar que não houve tentativa de “buscar” arquivos outros que os disponíveis no sistema Winchill.

No projeto SGDC, a maior dificuldade na análise é ocasionada pela classificação dos documentos como “interno”. A Thales Alenia Space (TAS)

134

tem processos e regras bastante rígidas quanto a classificação de informação sensível, mesmo tendo o autor participado do Programa de Absorção de Tecnologia (TAP – tradução livre de Technology Absortion Program) firmado entre a Agência Espacial Brasileira (AEB) e a TAS em 2013.

Em virtude dessas restrições a análise apresentada neste capítulo não consegue ter a mesma profundidade e de forma igualitária entre os projetos analisados, mas tenta mostrar de forma objetiva e elucidativa como se dá o processo de desenvolvimento de GSE nos três programas espaciais escolhidos.

4.2 Programa CBERS

4.2.1 Breve Histórico do Programa CBERS 3&4

Fruto de uma aliança de cooperação técnico-espacial da década de 80 entre Brasil e China que resultou no lançamento bem sucedido de dois satélites: o CBERS-1 em 1999 e o CBERS-2 em 2003.

A continuidade dessa cooperação ocorreu em 2002 com a assinatura de mais 3 satélites: CBERS-2B, CBERS 3 e CBERS 4.

O CBERS-2B, nasceu do aproveitamento de parte espólio existente do convênio anterior, e foi lançado em 2007. Enquanto isso outros dois satélites com cargas úteis completamente novas foram desenvolvidos baseados na plataforma existente, mas com uma série de modificações devido aos novas cargas úteis e a adequação do projeto da plataforma á componentes mais atuais. De fato as modificações na plataforma foram tantas que levou a uma lacuna de 6 anos entre o lançamento do CBERS-2B e do CBERS-3.

O CBERS-3 após muitos problemas de desenvolvimento causados sobretudo por dificuldades de compra de componentes listados no ITAR, somente foi lançado no final de 2013. O CBERS 3 foi marcado por uma falha no veículo lançador que não o colocou na órbita correta frustrando a todos.

135

O CBERS-4, reprodução fiel de seu antecessor o CBERS 3, foi integrado em tempo recorde de um ano, e lançando com sucesso em dezembro de 2014.

Figura 4.1 – Visão de raio-X do satélite CBERS 3.

Fonte: (INPE,2015)

4.2.2 Proposta de Análise

Para que se faça uma análise do desenvolvimento de GSE dos satélites CBERS 3 e CBERS4 é preciso que primeiro que sejam identificadas todas suas fontes de requisitos para o GSE.

Infelizmente o programa CBERS sofre da falta de ferramentas para gestão e rastreabilidade de requisitos como bem observa Almeida e reproduzido abaixo:

“Não foram criados processos e ferramentas para atender às exigências de rastreabilidade de requisitos do Programa CBERS. Injustificadamente, o Programa CBERS não mantém rastreabilidade de requisitos exigida em documentos de requisitos de garantia do produto e no guia de verificações.” (ALMEIDA,2011,p.135)

136

Além da falta de rastreabilidade, e em boa medida por causa dela, há muitas incoerências entre documentos. Em boa parte essas incoerências são causadas por documentos desatualizados, mas como não há processos de engenharia definidos, ferramentas de apoio ao gerenciamento de requisitos, esses documentos são simplesmente esquecidos desatualizados.

Dado esse contexto, neste capítulo foram analisados uma grande quantidade de documentos do programa CBERS que estão disponíveis no sistema de gerenciamento de documentação Windchill do INPE disponíveis entre 2014 e 2016.

Um dos objetivos da proposta inicial deste estudo era analisar a evolução temporal dos documentos que serviram de referencia para a criação dos documentos de especificação do GSE (Venticinque, 2015,p. 6). Porém essa análise não pôde ser feita já que o sistema de gerenciamento de documentos do CBERS não faz o controle de versões.

Não há um levantamento atual da quantidade de documentos, mas segundo registrado por Almeida (2011,p.137) um levantamento da quantidade de documentos do programa CBERS, configurado pelo lado brasileiro apenas, em 2010 chegou a cifra de mais de 9582 documentos distribuídos em 1007 pastas. Obviamente é humanamente impossível varrer uma quantidade tão grande documentos, mas acredita-se que as principais fontes de requisitos para GSE foram analisadas neste trabalho.

Uma outra justificativa para a quantidade tão grande de documentos é o fato de não haver processo bem claro quanto a criação de documentos. Muitos documentos foram criados sem que fosse feito um planejamento da árvore de documentos. Exemplo é o caso dos documentos “EM Special Electrical Test Joint Work Planning” (RB-MNG-0056) e “EM Electrical Test Plan” (RB–AIT– 0007), que possuem parte de seus conteúdos redundantes.

Mas apesar da quantidade enorme de documentos do programa CBERS 3 & 4, foram notadas muitas ausências de documentos, tais como: documentos

137

descritivos da solução de EGSE e MGSE. Os únicos descritivos do GSE são apresentados nas revisões PDR e CDR.

Possivelmente os responsáveis por cada pacote de trabalho do CBERS possam ter outros documentos (planilhas, análises, “trade-offs”, diagramas, entre outros) mas esse material não foi considerado nessa análise dado a dificuldade em juntar essas informações e também porque pelo próprio princípio de que os documentos de sistema devem ser configurados de acordo com a norma de Gerenciamento de Configuração e Informação (ECSS‐M‐ST‐ 40C:2009).

4.2.3 Árvore de Requisitos

Varrendo a documentação do programa CBERS 3&4 não foi possível achar

uma árvore requisitos de sistema. Para isso foi utilizado a árvore de requisitos fornecida por Almeida e reproduzida na Figura 4.2.

Figura 4.2 – Árvore de documentos de sistema do programa CBERS 3&4

Fonte: (ALMEIRDA,2011)

138

Conforme aponta Almeida, a colocação de requisitos nível hierárquico inferior em um documento de hierárquico superior compromete sua verificação e limita-se soluções (ALMEIDA,2011).

4.2.4 Fontes de Requisitos de GSE

O objetivo desta seção é fazer uma análise dos documentos de sistema que de alguma forma impõe requisitos ao GSE, ou seja quais são as entradas para preparação dos documentos de especificação de EGSE e de MGSE.

É possível levantar uma série de documentos que fornecem direta ou indiretamente requisitos ao GSE.

Após uma extensa pesquisa em documentos de sistema, subsistema e unidades, pode-se afirmar que as principais fontes de requisitos para GSE do programa CBERS estão contidos nos documentos listados abaixo:

1) Documento Plano de Desenvolvimento e Plano de Verificação; 2) Documentos de Sistema:

a) CBERS FM-3 AIT Work share and Responsibility;
b) Especificação de Requisitos do Satélite (RB-HDS-0023,INPE,2005); c) Especificação de Requisitos de Projeto e de Construção;
d) Especificação de Ambiente Espacial;
e) Especificação de Interferência Eletromagnética;
f) Desenhos mecânicos do satélite e seus equipamentos; 3) Documentos de Subsistemas/Equipamentos:
a) Documentos de Requisitos de Testes de Subsistemas:
b) Documentos de Especificação de Requisitos de Subsistemas: c) Especificação dos Testes de Sistema e de Subsistema
d) Documentos de Especificação de Interfaces (ICD) de Equipamento 4) Documentos de AIT:
a) Documento Requisitos Gerais para AIT; b) Plano de AIT (RBT-AIT-0002,INPE,2011); c) Plano de Teste Elétrico do Satélite;

5) Outras fontes de requisitos: a) Minutas de reunião;

b) Heranças de outros programas; c) Manual de Usuário do Lançador; d) Normas na área espacia

139

Esses documentos fornecem direta ou indiretamente requisitos ao GSE.

Possivelmente há outros documentos contendo requisitos diretos e indiretos ao GSE, mas isso não tira a importância dessa análise cujo objetivo é apenas tentar mostrar como ocorreu o processo de desenvolvimento do GSE do programa CBERS 3&4.

Nas seções subsequentes, serão apresentados e analisados os documentos listados acima da seguinte forma:

O Documento Plano de Desenvolvimento; · Os documentos de sistema;
Os documentos de subsistema; · Os documento de AIT;
Outro documentos .

Após mostrar todas as principais fontes de requisitos do GSE, finalmente será apresentado GSE especificado e desenvolvido para os satélites CBERS 3 e CBERS 4 na Seção 4.2.6.

Ao final será apresentado algumas conclusões sobre essa análise.

4.2.4.1 Plano de Desenvolvimento

Esta seção faz uma análise do documento Satellite Development and Test Plan (RB-MNG-0002,INPE,2005) unicamente em busca de requisitos para GSE.

Embora não seja o objetivo do documento Satellite Development and Test Plan impor requisitos ao GSE, este documento baliza não apenas o desenvolvimento do GSE em termos de disponibilidade mas também impões algumas necessidades do GSE sob o ponta de vista do gerenciamento do projeto, ao apresentar todos os modelos e seus respectivos planos de testes conforme pode ser visto na Figura 4.3.

140

Figura 4.3 – Plano de Testes dos Modelos do CBERS 3/4

Fonte: (RB-MNG-0002,INPE,2005)

O documento apresenta poucas citações ao GSE (EGSE e MGSE) que são

reproduzidas a seguir:

A primeira citação é a necessidade de estudos e definição do GSE durante a fase B do ciclo de vida do satélite ou seja “…o GSE necessário para desenvolvimento, AIT, produção, manuseio, armazenamento e transporte do satélite”.

Note que os termos “desenvolvimento” e “produção” são utilizados como necessidades para serem atendidas pelo GSE, o que, como veremos mais tarde na Seção 4.2.6 não faz parte do escopo e dos requisitos do GSE especificado e nem do GSE desenvolvido.

141

1) “Seção 4.2.1 – Atividades do Sistema da Fase B

h) Estudos e definição dos equipamentos de suporte em solo (GSE) necessários para o desenvolvimento, produção, AIT, manuseio, armazenamento e transporte do satélite” (RB-MNG-0002, INPE, 2005, p.4).

Outro ponto a ser notado é que não há nenhum registro de que forma esses estudos sobre o GSE foram feitos ou apresentados. Possivelmente o único resultado desses estudos tenham sido o documento final de Especificação do EGSE e Especificação MGSE.

Outra citação ao GSE é feitas na seção que descreve os objetivos da Revisão Preliminar de Projeto (PDR) na qual inclui a necessidade da disponibilização dos documentos de especificação do EGSE e do MGSE.

2) “Seção 5.1 – Revisão Preliminar de Projeto de Sistema (Sys PDR)

“Para atingir esses objetivos, um conjunto de documentos e dados de referência deve ser preparado e distribuído antes das apresentações orais da PDR:

[…]

7 Especificação MGSE

8 Especificação EGSE”(RB-MNG-0002, INPE, 2005, p. 6).

Curiosamente na seção que descreve os objetivos do Revisão Crítica do Projeto de sistema (CDR) não aparece nenhuma menção aos documentos de especificação do MGSE e do EGSE e muito menos ao Pacote de Dados do EGSE e MGSE conforme a norma ECSS solicita.

A quarta citação é feita apenas ao EGSE quanto a parte dos objetivos dos testes de performance no Modelo Elétrico (EM) do CBERS, que pede para verificar a compatibilidade do EGSE incluindo em termos de Compatibilidade Eletromagnética (EMC).

3) “Seção 6.2.4 – Modelo Elétrico (EM)

“O objetivo do teste de desempenho elétrico é verificar se todos os equipamentos a bordo, cabos e EGSE podem ser coordenados, integrados e compatíveis com EMC” (RB-MNG-0002, INPE, 2005, p.10).

142

Ciclo de Vida do GSE

Embora não seja objetivo do documento Plano de Desenvolvimento do Satélite apresentar cronograma macro do projeto, fica claro na Seção 5.4 do documento que o GSE deve estar disponibilizado integralmente para as atividades de AIT do Modelo Elétrico do CBERS, e que o fim das atividades de AIT do EM devem ocorrer antes da CDR de sistema, conforme texto reproduzido abaixo:

5.4 – Revisão Crítica de Projeto de Sistema (CDR Sys) Os objetivos desta revisão são:

A) Examinar o projeto detalhado do satélite e avaliar a sua integridade e conformidade com as especificações com base em: 1 Resultados dos testes de EM (para aspectos de desempenho elétrico), RM (para aspectos de EMC) TM (para aspectos térmicos) e SM (para aspectos mecânicos); “(RB-MNG-0002, INPE, 2005, p.7).

O mesmo acontece para o GSE relacionado ao Modelo Térmico (TM), ao

Modelo Radioelétrico (RM) e ao Modelo Estrutural (SM) que devem estar disponíveis durante a fase C do projeto do sistema já que todos esses modelos devem ser testados e seus resultados devem ser apresentados para a CDR de Sistema.

Uma restrição é dada aos testes do Modelo Térmico, cuja a estrutura utilizada deve ser a estrutura do Modelo de Voo do CBERS 3 (FM3). Porém a estrutura FM3 só pode ser fabricada após os testes estáticos e dinâmicos do Modelo Estrutural (SM).

4.2.4.2 Requisitos de Sistema

4.2.4.2.1 WBS e PBS

Durante a análise dos documentos do CBERS nas seções subsequentes, serão exemplificadas algumas incoerências na documentação apenas com o intuito de reforçar a necessidade de melhorar os processos de engenharia de sistemas. Essas incoerências além de criar dificuldades para esta análise, cria

143

dificuldades para as equipes de desenvolvimento envolvidas e cria também dificuldades para consolidação de conhecimento na organização extremamente útil para os novos projetos.

Um exemplo de incoerência entre documentos começa no documento intitulado

Program Work Breakdown Structure (WBS), que é um documento de alto nível na hierarquia do projeto, datado de novembro de 2004. O WBS não contém nenhuma referência ao desenvolvimento do GSE (R-MNG-0004,INPE,2004), ao passo que o documento Satellite Product Matrix (RB-MNG-0010,INPE,2008), datado de maio de 2008, e do qual o WBS deveria derivar, lista ambos os produtos EGSE e o MGSE.

Esse problema não fica limitado a apenas um documento desatualizado já que outros documentos são criados a partir de documentos existentes como é o caso do documento Critical Design Review – Section 10 – Program Management datado de fevereiro de 2010, que baseado no WBS também não menciona a existência do EGSE e MGSE (RB-REV-0046/00,INPE,2010).

Algumas atualizações do WBS aconteceram depois do projeto em andamento por conta dos documentos de entendimentos entre INPE e CAST que ajustam a divisão de trabalho para os níveis inferiores da hierarquia do sistema, mas não são atualizados no documento do WBS do projet. Exemplo disso acontece com documento Work Share for CBERS 3&4 Development Models AIT (RB-MNG-0052,INPE,2004), que complementa o WBS da seguinte forma:

“3.5. Equipamento de Suporte em Solo (GSE)

A) O INPE é responsável pelo fornecimento do Equipamento Mecânico de Suporte ao Solo (MGSE) a ser utilizado nas atividades da AIT realizadas no Brasil.
B) A CAST é responsável pelo fornecimento do Equipamento Mecânico de Suporte ao Solo (MGSE) a ser utilizado nas atividades da AIT realizadas na China.
C) O INPE é responsável por fornecer o OCOE e os SCOEs dos subsistemas brasileiros do Equipamento Elétrico de Suporte em Solo (EGSE) utilizados nas atividades do AIT realizadas no Brasil e na China.
D) A CAST é responsável por fornecer os SCOEs para os subsistemas chineses do EGSE utilizados nas atividades do AIT realizadas no Brasil e na China.
E) O INPE é responsável pela integração do EGSE, a ser utilizado nas atividades da AIT realizadas no Brasil e na China. O CAST apoiará esta integração” (RB-MNG-0052,INPE,2004).

144

4.2.4.2.2 Documentos de Sistema

O documento de Especificação do Satélite do CBERS 3&4 (RB-HDS-

0023,INPE,2005) e o documento Especificação de Design e Construção do CBERS 3&4 (RB-DCS-0001,INPE,2011) são os documentos de mais alto nível em termos de requisitos para o satélite como também para o GSE.

Os dois documentos juntos impõe requisitos indiretos, como por exemplo requisitos de interface com o satélite e seus subsistemas discutido na Seção 4.2.4.3, e requisitos diretos ao EGSE e MGSE conforme pode ser observado nos trechos abaixo:

“3.1.2.7 – Interface do Satélite com o Equipamento de Suporte em Solo

A interface entre o satélite e o Equipamento Elétrico de Suporte em Solo – EGSE deve ser definida no documento CBERS 3 e 4 de satélite para especificação de interface EGSE (RB-IFS-0006).

O EGSE e MGSE devem ser projetados para serem utilizados durante a integração e teste do satélite “(RB-HDS-0023, INPE, 2005).

“4.7 – Disposições de Manuseio

Cada unidade com massa superior a 15 Kg deve estar equipada com pontos de manuseamento (por exemplo, bucha roscada) que permitam a ligação do MGSE de manuseamento para integração ou desmontagem.

[…]

6.3.2.6 – Aterramento do EGSE

Aterramento da estrutura do Simulador do Painel Solar (SAS) deve estar no massa das instalações de teste.

A ligação ao massa do EGSE deve ser definida na respectiva especificação.

A estrutura do satélite deve fornecer pontos adequados para aterramento para EGSE e instalações de teste. Esses pontos devem ter resistência mecânica e acesso para fácil conexão / desconexão “(RB-DCS-0001, INPE, 2011).

4.2.4.3 Documentos de Subsistema/Unidades

Requisitos para o GSE de sistema são demandados também nos documentos

de definição de design dos subsistema e unidades. Esses documentos fornecem muitos dos requisitos, já que o GSE tem por missão dar suporte à operação e aos testes durante integração ao sistema e após durante os testes

145

de performance que comprovam que o subsistema integrado ao satélite atende aos requisitos funcionais e de performance demandados ao subsistema.

Dentro desta categoria de documentos estão os seguintes documentos analisados

a) Documentos de Requisitos de Testes de Subsistemas;
b) Documentos de Especificação de Requisitos de Subsistemas; c) Especificação dos Testes de Sistema do Subsistema;
d) Documentos de Especificação de Interfaces (ICD) de Equipamentos;

4.2.5 O Subsistema de Suprimento de Energia – EPSS

Para esta análise foi escolhido o Subsistema de Suprimento de Energia – EPSS.

A Figura 4.4 apresenta a resumidamente a Árvore Hierárquica de Produtos

(PBS tradução livre de Produc Breakdown Structure) do programa CBERS 3&4. Por simplicidade os subsistemas de carga útil foram suprimidos da figura e os subsistemas EPSS e SYSC estão em destaque pois todas as necessidades em termos de GSE para as atividades de AIT serão analisados com mais detalhes neste capítulo.

Por razões históricas a função de distribuição e proteção do barramento potência principal do CBERS está alocado no subsistema SYSC (Almeida, 2011), no equipamento chamado de MDC (Master Distribution Controller).

Figura 4.4 – Estrutura da Árvore de Produto – PBS do CBERS 3 & 4

Fonte: Adaptado de R-MNG-0004 (INPE,2004)

146

No programa CBERS, o produto EGSE (produto RBT0000 na Figura 4.2) é de responsabilidade compartilhada entre brasileiros e chineses, mas coube ao Brasil a responsabilidade de integrar e disponibilizar o EGSE, bem como a responsabilidade de fornecer o OCOE – Overal Checkout Equipment que é em linhas gerais o elemento central e de controle do EGSE.

O desenvolvimento do subsistema EPSS (produto RBD0000 na figura 4.2) ficou sob responsabilidade brasileira. O INPE fez a especificação do subsistema EPSS e do nível abaixo na hierarquia de produto: os equipamentos, SAG, Shunt, Bateria, BDR (Regulador de Descarga da Bateria), BCHC (Controlador de Carga e Aquecimento da Bateria) e oito DCDC (Conversores de Corrente Continua), foi então contratada a empresa Aeroeletrônica para o desenvolvimento dessas das unidades do EPSS, excluindo o SAG e a Bateria, que tiveram contratação a parte, o primeiro desenvolvido pela Orbital Engenharia e o segundo comprado da empresa chinesa Sisp.

Coube também a Aeroeletrônica o desenvolvimento dos Equipamentos de Suporte Elétrico – ESE das unidades contratadas e desenvolvidos para teste individual das unidades a serem entregues: Shunt, BDR, BCHC e DCDCs. (RBD-SOW-1001,INPE,2004).

Tabela 4.1 – Tabela com o Cronograma e a Quantidade de ESEs fornecidos para o EPSS

147

A contratação das unidades mencionadas e de seus equipamentos de testes (ESE) foram baseadas nos documentos de especificação do subsistema EPSS, dos equipamentos do EPSS, da especificação do ESE e do próprio “Projeto Básico” (RBD-SOW-1001,INPE,2004) todos, preparados pelo INPE e listados abaixo.

Lista de documentos que complementam Projeto Básico de Contratação do EPSS:

“

a) Shunt Regulator (SHUNT) Specification (RBDA-HDS-1001);
b) Battery Discharge Regulator (BDR) Specification (RBDB- HDS-1002);
c) Battery Charge and Heating Controller (BCHC) Specification (RBDC-HDS-1003); d) DC/DC Converter 01 Specification (RBDE-HDS-1005);
e) DC/DC Converter 02 Specification (RBDF-HDS-1006); f) DC/DC Converter 03 Specification (RBDG-HDS-1007); g) DC/DC Converter 04 Specification (RBDH-HDS-1008); h) DC/DC Converter 05 Specification (RBDI-HDS-1009); i) DC/DC Converter 06 Specification (RBDJ-HDS-1010); j) DC/DC Converter 07 Specification (RBDK-HDS-1011); k) DC/DC Converter 08 Specification (RBDL-HDS-1012);
l) Electrical Power Supply Subsystem Specification (RBD-HDS-0004)
m) Especificação dos Equipamentos de Suporte Elétrico (ESE) (RBD-HDS-1014)” (RBD-SOW-1001,INPE,2004).

A integração do subsistema EPSS está no escopo do AIT do satélite, cuja responsabilidade ficou com o Laboratório de Integração e Testes – LIT do INPE (R-MNG-0004,INPE,2004) e (RBD-SOW-1001,INPE,2004).

4.2.5.1 Requisitos do EPSS

4.2.5.1.1 Requisitos de Sistema do EPSS

Como parte do objetivo do AIT de sistema é verificar os requisitos de sistemas e que o GSE é o conjunto de ferramentas que possibilitam essas atividades de AIT, é de extrema importância que esses requisitos sejam analisados sob o ponto de vista de verificação.

148

O documento CBERS 3&4 Satellite Specification (RB-HDS-0023,INPE,2005) lista os requisitos técnicos do EPSS em alto nível. A Tabela 4.2 lista os requisitos de sistema do EPSS e com o intuito de mostrar as necessidade em termos de EGSE de acordo com o cruzamento dos elementos de EGSE descritos no documento de especificação do EGSE (RBT-HDS-0022,INPE,2004).

O documento de especificação do EGSE já traz a lista de elementos do EGSE necessários as atividade de AIT de acordo com o que foi levantado na época. A idéia desta análise é levantar as necessidades em termo de GSE baseado nos requisitos de sistema.

Os documentos de requisitos do programa CBERS não seguem as recomendações da engenharia de requisitos conforme apontado em Almeida, 2011. Isso dificulta a análise já que muitos dos requisitos não são verificáveis.

Adicionalmente foi acrescentada uma coluna de aplicabilidade de cada um dos requisitos com relação a sua verificação durante o AIT de sistema ou nos níveis mais baixos da hierarquia do sistema. Essa coluna foi adicionada para justificar eventuais ausências na Tabela 4.2.

A análise da Tabela 4.2 mostra que em termos de EGSE de sistema, a necessidade para atender unicamente ao requisitos do subsistema de potência é mostrado.

149

Tabela 4.2 – Lista de Requisitos para EPSS no Documento de Requisitos do Satélite

Requisitos do EPSS (Referência ao documento e traduzido para o português)	Aplicabilidade (*)	EGSE a nível de sistema (*)
3.5.3 $1 – O EPSS deve prover energia elétrica (ao barramento principal do satélite)*, em várias tensões, durante todas as fases da missão projetada para a vida do satélite		OCOE
3.5.3 $2 – O EPSS deve converter a luz solar em energia elétrica através do SAG	Requisito verificável apenas a nível de unidade. Porém a nível de sistema é necessário verificar a integração do SAG com o Satélite	Fonte de Luz MGSE SAG;
3.5.3 $3 – O EPSS deve condicionar a energia elétrica gerada no SAG.		SAS; OCOE
3.5.3 $4 – A energia elétrica gerada pelo SAG deve ser armazenada em baterias.		SAS; OCOE
3.5.3 a) O SAG deve prover energia elétrica (ao barramento do principal do satélite)* durante o período de luz do sol.		SAS; OCOE
3.5.3 b) A bateria deve prover energia elétrica (ao barramento principal do satélite)* durante o período de eclipse.		OCOE
3.5.3 c) A bateria deve prover energia elétrica complementar à energia do SAG durante os pico de carga (no barramento principal)*.		SAS; OCOE
3.5.3 d) A potência de saída do SAG (Fim de vida) deve ser superior á 2300W.	Requisito verificável apenas a nível de unidade.
3.5.3 e) A tensão do barramento principal deve estar entre 28V ± 0.6V.		SAS; OCOE
3.5.3 f) A eficiência dos conversores DC/DC deve ser superior á 73%	Performance somente verificável a nível de unidade em condições nominais de projeto.	–
3.5.3 g) A regulação de tensão (de saída)* dos conversores deve ser de ± 1%.	Performance somente verificável a nível de unidade.	–
3.5.3 h) A capacidade de (armazenamento de carga)* da bateria deve ser superior a 90Ah.	Performance somente verificável a nível de unidade.	–
3.5.3 i) O DOD da bateria não deve ser superior a 20% (durante todas as fases da missão)*.	Este requisito não é completo e pode não ser consistente com o requisito de capacidade de armazenamento de carga da bateria #10	OCOE.

* Nota: Complementado/ preenchido pelo autor

Fonte: Coluna 1 baseada em R-MNG-0004 (INPE,2004), Colunas 2 e 3 preenchidas pelo autor

150

4.2.5.1.2 Plano de Testes Elétricos do EPSS

Um dos mais importante documento de requisitos para o EGSE do EPSS é o

documento EPSS Test Specification – System and Subsystem Levels (RB-TES-0003). Este documento trás a lista de testes aplicáveis ao subsistema EPSS ao longo das atividades de AIT39, e mostradas na Tabela 4.3.

Tabela 4.3 – Lista de Aplicabilidade dos Testes Funcionais e de Performance do subsystema EPSS

Test	State
Test	A		B	C1	C 2	D	EMC
TSTD # 01 – EPSS Input Power Lines Verification (EPSS+SYSC+EGSE)	T
TSTD # 02 – EPSS Internal Power Lines Verification	T
TSTD # 03 – Main Bus Voltage Verification (EPSS + SYSC)	T
TSTD # 04 – Secondary Voltage Verification (EPSS + SYSC)	T
TSTD # 05 – EPSS TM/TC Verification		T	X	X	X	X
TSTD # 06 – Shunt Channels Verification		T
TSTD # 07 – BDR Channels Verification		T
TSTD # 08 – BCHC – Battery Charge and Stop the Charge Function		T
TSTD # 09 – Shunt MEA Redundancy Verification		T
TSTD # 10 – BCHC – Heater Control			T	X	X	T
TSTD # 11 – BCHC – EOC Curves			T
TSTD # 12 – DCDC Converters Input Voltage Verification – Loaded			T
TSTD # 13 – Equipment Secondary Input Voltage Verification – Loaded			T
TSTD # 14 – MDC Main Bus Voltage during Eclipse and Sunlight Period			T	X	X	X
TSTD # 15 – MDC Main Bus Voltage Transient due to Sunlight/Eclipse Transitions			T	T	X	X
TSTD # 16 – MDC Main Bus Voltage Quality due to Special Loads			T	T	X	X
TSTD # 17 – MDC Main Bus Voltage transient due to Surge Current			T	T	X	X
TSTD # 18 – MDC Main bus voltage disturbance due to Pyrotechnics			T	T
TSTD # 19 – Main Bus Current Level x Subsystem			T	X	X	X
TSTD # 20 – Main Bus Current Level due to Satellite Operation Modes			T	T	X	X
TSTD # 21 – Battery DOD and EPSS Power Balance due to Satellite Operating Modes			T			T
TSTD # 22 – Launch Phase Battery DOD			T			T

NOTE : (*) Performed before start state A; T – Test X – Monitoring only

Fonte: (RB-TES-0003,INPE,2008)

39 Erroneamente o documento “EPSS Tests – System and Subsystem” – (RB-TES-0003,INPE,2008) afirma que a tabela “…apresenta os requisitos elétricos a serem verificados durante o AIT do CBERS3”, quando de fato a tabela apenas correlaciona os testes elétricos definidos para o EPSS aplicados aos estados progressivos de integração do satélite durante na fase inicial do AIT. O documento não trás a aplicabilidade dos testes de EPSS para as demais fases de AIT como testes ambientais e testes pós ambientais, dificultando assim o planejamento do AIT e levantamento de EGSE necessário durante as fases de AIT.

151

4.2.5.2 Plano de AIT

O Plano de AIT (RBT-AIT-0002,INPE,2011) é um documento de planejamento das atividades de AIT e deve responder principalmente aos documentos “Plano de Desenvolvimento e Teste” (RB-MNG-0002,INPE,2005) e “Requisitos Gerais de AIT” (RBT-AIT-0001,INPE,2011).

No documento Requisitos Gerais de AIT estão, em termos gerais, os requisitos gerais, de qualidade e de planejamento para execução das atividades de AIT, e enumera os seguintes objetivos para o plano de AIT (RBT-AIT-0001,INPE,2011):

Sequência de AIT;
Descrição das atividades de montagem, de integração e de testes, incluindo os testes ambientais;
Equipamentos (GSE) e infraestrutura para a execução do plano.

Além desses dois importantes documentos, outros documentos também são considerados para a elaboração do Plano de AIT:

Guia de Atividades da Garantia de Produto para Fase de AIT; · Plano de Gerenciamento do Programa;
Especificação de EGSE; · Especificação de MGSE; · Especificação do Satélite;
Procedimento de Auditorias de Garantia de Produto; · Matriz da Árvore de Produtos;
Requisito de Design e Construção; · Especificação Ambiental;
Especificação de EMC.

O documento Plano de AIT apresenta a sequência de atividades de integração e testes a serem desenvolvidas de forma lógica a fim de se obter um alto grau de confiança no produto final. Para isso o Plano de AIT lista três objetivos principais (RBT-AIT-0002,INPE,2011):

Organizar as atividades de montagem, integração e testes da maneira mais eficiente do ponto de vista de tempo e custo;

152

Garantir que o sistema e os subsistemas atendam a todos requisitos funcionais e de performance estabelecidos em uma válida referência;
Garantir que todos os testes requeridos sejam executados.

Para que se atendam aos objetivos acima, as atividades de AIT são separadas

em fases, conforme Tabela 4.4, de acordo com a progressão do estado de montagem do satélite (Figura 4.5).

Tabela 4.4 – Fases de AIT versus Estado do Satélite CBERS

Fonte: Baseado em RBT-AIT-0002 (INPE,2011)

O plano de AIT cobre as atividades até a preparação para envio a base de

lançamentos e não cobre as atividades da base de lançamento.

As atividades na base de lançamento são planejadas em um outro documento denominado CBERS FM4 Launching Base Activities Plan (RB-AIT-0097(F4),INPE,2014). Esse documento normalmente é disponibilizado somente as vésperas do envio do satélite á base como pode ser observado pela data da versão 0 (primeira versão) ser de 20 de outubro de 2014 e o lançamento ter ocorrido em 7 de dezembro de 2014.

153

Figura 4.5 – Concepção dos Estados de Montagem do Satélite CBERS

Fonte: (RBT-AIT-0002,INPE,2011)

154

Figura 4.6 – Sequência do AIT do CBERS

Fonte: (RBT-AIT-0002,INPE,2011)

4.2.5.2.1 Estado A

O estado A é o início da integração e verifica principalmente as interfaces

básicas dos equipamentos: aterramento, potência e alguns telecomandos on/off.

Configuração:

Módulos SM e PM com as unidades montadas exceto SAG, antenas e painéis de fechamento;
Módulos SM e PM conectados via cabo extensores, pertencentes ao EGSE.

Atividades nessa fase:

Verificar resistência de aterramento (bounding) das unidades; · Verificar interfaces de potência;
Verificar o correto funcionamento dos barramentos de potência; · Verificar o funcionamento dos subsistemas.

155

4.2.5.2.2 Estado B

O Estado B é dividido em vários modos de teste com o objetivo de verificar a

performance dos subsistemas e suas interfaces.

Configuração:

Idêntica ao estado A;
Instalação dos simuladores de imagens para as câmeras.

Atividades nessa fase:

Verificar individualmente a performance de cada subsistema; · Verificar as interfaces entre os subsistemas (exceto potência)
Verificar a correta execução dos telecomandos e respectivas telemetrias;
Verificar a performance dos subsistemas em várias configurações;
Monitorar o funcionamento dos subsistemas em vários modos de operação;

4.2.5.2.3 Estado C

O Estado C é dividido 2 sub estados: C1 e C2, sendo que a diferença entre esses estados é que no C1 as interfaces de RF são feitas de forma conduzida, via cabos, e no C2 as antenas são montadas e as interfaces de RF são feitas de forma irradiada (RB-AIT-0007,INPE,2008).

Configuração C1:

Módulo PM é acoplado ao módulo SM; · Interfaces de RF via cabo;
Simuladores de imagens das câmeras montados

Configuração C2:

Módulo PM é acoplado ao módulo SM;
Antenas montadas interface irradiada de RF;
Simuladores de imagens das câmeras desmontados

Atividades nessa fase:

156

Verificar a autocompatibilidade dos subsistemas após o acoplamento dos módulos SM e PM
Verificar a performance dos subsistemas em várias configurações na configuração final dos cabos de baixa frequência;
Monitorar o funcionamento dos subsistemas em vários modos de operação;
Verificar o funcionamento das interfaces irradiadas após integração das antenas (estado C2).

4.2.5.2.4 Estado D

O Estado D é a configuração mais completa do satélite. Este estado é equivalente ao estado C2 com fechamento dos painéis laterais do satélite. A comunicação com o satélite é toda feita de forma irradiada pelas antenas.

Configuração D:

Módulo PM é acoplado ao módulo SM; · Painéis laterais montados;
Antenas montadas e interface irradiada de RF;
Simuladores de imagens das câmeras desmontados.

Atividades nessa fase:

Verificar a autocompatibilidade dos subsistemas na configuração final; · Verificar a performance dos subsistemas na configuração final;
Preparar o satélite para os testes ambientais.

4.2.6 EGSE do CBERS 3&4

4.2.6.1 Visão Geral

Os requisitos do EGSE para testes e operações do satélite são especificados no documento “Especificação do EGSE”. De acordo com esse documento as funções do EGSE são (RBT-HDS-0022,INPE,2004):

“O EGSE é o conjunto de equipamentos de teste necessária para:

1. Executar todos os testes funcionais elétricos durante AIT dos satélites, a partir de integração elétrica até a fase de lançamentos;

157

2. Executar os testes de inspeção de recebimento nas unidade / subsistema após transporte ou antes da unidade ser montada no satélite.” (RBT-HDS-0022,INPE,2004, grifo do autor).

Note que uma função extra foi adicionada ao EGSE para executar os testes de

inspeção de recebimento das unidades/subsistemas após transporte dos subsistemas, o que normalmente extrapola a missão do EGSE de sistema.

A consequência desse requisito é a alteração da missão do EGSE estabelecida no documento de requisitos de especificação do satélite (RB-HDS-0023,INPE,2005).

A função “testar unidades/subsistema em bancada” para o EGSE tem muitas implicações acarretando a necessidade de hardware adicional. Esse requisito somente foi atendido parcialmente pelos elementos de EGSE dos subsistemas brasileiros, além de ter criado uma sobreposição de funções com o ESE de subsistema.

Embora esse requisito não tenha rastreabilidade, a razão dessa inclusão no documento de especificação do EGSE é que todas as unidades dos subsistemas brasileiros deveriam passar por testes funcionais e de performances em bancada após transporte, em solo chinês. Por conta disso muitos equipamentos de testes de subsistemas foram triplicados para que permitissem testes simultâneos das unidades em produção na empresa contratada, das unidades em testes no INPE e das unidades entregues na China, conforme pode ser visto na Tabela 4.1.

A Figura 4.7 apresenta um diagrama em blocos do EGSE ilustrando seus componentes em uma configuração normal de operação, onde as interfaces de RF com o satélite são feitas de modo irradiado. Diferentes configurações de operação são previstos para o EGSE, que basicamente dependerá da configuração do satélite e em qual fase de integração se encontra.

158

Figura 4.7 – Diagrama em blocos do EGSE CBERS 3&4

Fonte: Adaptado de RBT-HDS-0022 (INPE,2004)

Figura 4.8 – Conceito de Operação do EGSE durante AIT

Fonte: Adaptado de RBT-HDS-0022 (INPE,2004)

159

No total o EGSE é composto de 21 componentes conforme breve descrição na Tabela 4.5.

Tabela 4.5 – Componentes do EGSE

Fonte: (RBT-HDS-0022,INPE,2004)

160

4.2.6.1.1 Interfaces EGSE

O documento de Especificação de Requisitos do EGSE descreve interfaces

externas do EGSE com o satélite e lançador, como também detalha as interfaces internas, entre elementos do EGSE, conforme lista abaixo:

Interfaces Externas – EGSE e os outros sistemas: o EGSE ßàUsuário;

o EGSE ßàLinhas de Potência; o EGSE ßàSatélite;

Conector de Separação; § Conectores do Satélite; § Antenas e Cabos de RF;
Simuladores de Cena para as cameras IRS, MUX, PAN e WFI;
Simulador Solar;
Estimuladores dos sensores solares e de estrelas do satélite;
Fonte radiadora para o detector do SEM; § Trocadores de Calor;
Interfaces Internas – EGSE: o Protocolos de rede; o OCOE ßàTMTC;
OCOE ßàEstação de Telecomando; § OCOE ßàEstação de Telemetria;

o OCOE ßàSCOE; o SCOE ßàSCOE:

PIT SCOE ßàIRS SCOE; § PIT SCOE ßàPAN SCOE;
MWT SCOE ßàMUX SCOE; § MWT SCOE ßàWFI SCOE;
GWC SCOE ßàSYSC SCOE; § GWC SCOE ßàEPSS SCOE;
GWC SCOE ßàEstação TMTC; § TTCS SCOE ßàEstação TMTC.

4.3 SGDC

Esta seção tem por objetivo fazer uma introdução ao satélite SGDC e mostrar algumas das práticas com relação aos Equipamentos de Suporte em Terra GSE utilizados.

161

Para que se faça uma análise do processo de desenvolvimento de GSE do satélite SGDC é preciso contextualizar como são feitos os desenvolvimentos dos satélites de telecomunicações na Thales Alenia Space.

Devido a acordo de confidencialidade no Programa de Absorção de Tecnologia

– TAP, esta análise será feita apenas utilizando como referência o material classificado como aberto fornecido pela Thales durante os cursos iniciais e avançados do TAP entre 2014 e 2015, material aberto disponível na internet e observações feitas pelo autor durante sua participação das atividades de treinamento dentro do desenvolvimento e realização do satélite SGDC como parte do programa de absorção tecnológica.

4.3.1 Introdução

Um dos objetivos prioritários da Estratégia Nacional de Defesa (END) é projetar, fabricar e lançar satélites geoestacionários de comunicações e de sensoriamento remoto (MD,2008).

Em 2011 o Governo toma iniciativas para a construção do Satélite

Geoestacionário de Defesa e Comunicações Estratégicas (SGDC), que visa atender a demanda por comunicações estratégicas oficiais (civis e militares) e apoiar o Programa Nacional de Banda Larga (inclusão digital) PNAE 2012-2021 (AEB, 2012).

Com o objetivo de atender às diretrizes e prioridades da Política Nacional de Desenvolvimento das Atividades Espaciais (PNDAE) e da Estratégia Nacional de Defesa (END), Embraer e TELEBRÁS juntam esforços para formar a Visiona Tecnologia Espacial em 2012 (VISIONA, 2016).

Em 2013, a Visiona é contratada pela TELEBRÁS para ser a empresa gestora do contrato do SGDC. E ao final de 2013 a Thales Alenia Space é selecionada para ser a fornecedora do SGDC (VISIONA,2016).

O contrato de fornecimento do satélite SGDC também contempla um acordo de

absorção tecnológica, chamado de TAP – Technological Absorption Program, onde vários engenheiros brasileiros, de várias áreas de conhecimento e

162

instituições brasileiras, são enviados para acompanhar, nas dependências da Thales Alenia Space, todas as etapas do projeto sistêmico ao AIT (THALES,2015a).

A Thales é a líder europeia em sistemas satelitais, e conta com 30 anos de

experiência em plataformas de satélites geoestacionários.

Essa experiência permite a Thales assegurar a seus clientes cronogramas enxutos, a ponto de desenvolver um satélite de comunicações do porte do SGDC em até 31 meses. Segundo a Thales, essa eficiência é justificada devido aos seguintes fatores (THALES,2012a):

Baixa dependência: Extensiva fabricação “in house”, abrangendo todas as unidades críticas da plataforma e a maioria das unidades de carga útil;
Nenhum risco na cadeia de fornecedores: contratos de longo prazo com os principais fabricantes e utilização de unidades recorrentes na plataforma Spacebus. Isso faz com que se tenha peças de reposição disponíveis e margens de segurança previsível;
Infraestrutura otimizada: Cronograma de AIT reduzido e sob o mesmo teto: da produção de estrutura à expedição ao final do AIT.

4.3.2 A Organização Desenvolvedora – Thales Alenia Space

A Thales Alenia Space é uma join venture formada em 2007 entre a francesa Thales e a italiana Finmeccanica. Hoje Thales Alenia Space esta conta com 40 anos de experiência em sistemas espaciais e de telecomunicações.

Somente a Thales Alenia Space emprega 7500 funcionários espalhados em 9

instalações industriais em 5 países: Espanha, França, Itália, Bélgica e Alemanha. O Grupo Thales no total emprega 65 mil funcionários espalhados em 56 países (THALES,2015c).

Na França, a unidade da Thales em Cannes é responsável pelo

desenvolvimento da especificação de sistema, a fabricação da estrutura, o fornecimento da plataforma, o AIT do módulo de serviço e posteriormente o AIT do satélite. Após o lançamento a Thales Cannes ainda é responsável pelas

163

operações nas primeiras órbitas (LEOP – Launch and Early Orbit Phase) e testes iniciais em órbita (IOT – In Orbit Test).

A unidade da Thales em Toulouse fica responsável pelo projeto e desenvolvimento e fabricação da carga útil, integração e testes do módulo CM.

A grande parte dos produtos são desenvolvidos na própria TAS, principalmente na carga útil, algumas unidades são fornecidas por organizações externas entre elas: baterias, refletores das antenas, rodas de reação, giroscópio, sensor de estrela e o SST.

4.3.2.1 Gerenciamento de Processos

A Thales utiliza a ferramenta de gerenciamento de sistemas e processos

chamado Chorus 2.0. A principais características do Chorus 2.0 são listadas abaixo (THALES,2012c):

Sistema de Referencia:

o Identifica e aplica os processos nos vários níveis e domínios; o Descrição dos processos e seus documentos;

o Formatos e estrutura para documentos; o Manuais de qualidade;

o Compartilhamento de boas práticas;

Documento organizacionais e de governança: o Regras e políticas

o Diretivas;

o Memorandos, notas organizacionais.

A ferramenta Chorus 2.0 permite que toda a organização, incluindo as

unidades em outras localidades de compartilhar prática, processos e regras de governança.

O Chorus 2.0 também possui um sistema de implementação e verificação de processos que facilita a implementação, verificação e controle dos processos organizacionais de acordo com as práticas do CMMI® . A ferramenta também possibilita suporte à a relatórios e análises baseado nas estatísticas dos registros.

164

Essa ferramenta permite à Thales mantenha conformidade com as práticas do

CMMI® , CMMI-DEV, CMMI-ACQ, CMMI-SVC com maturidade nível 2 e 3

(THALES,2012c).

4.3.3 O satélite SGDC

O satélite SGDC possui duas cargas úteis que incluem 50 repetidores na

banda ka para atender ao Programa Nacional de Banda Larga o PNBL e 7 repetidores na banda X para atender ao Estratégia Nacional de Defesa (END) (THALES,2013).

O satélite SGDC é baseado na plataforma Spacebus C, que em 2015

completou 10 anos de operação do primeiro satélite baseado nessa plataforma o satélite Star One AMC-12 (THALES,2015a).

Figura 4.9 Família de plataformas desenvolvidas pela Thales, com destaque ao Spacebus C4

Fonte: Adaptado de THALES (2012a)

A plataforma Spacebus C4 conta com a aviônica 4000 que é modular e pode ser customizada de acordo com a necessidade de potência da carga útil. A aviônica 4000 possui barramento de 100 V e dependendo da configuração de painel solar e PCU pode chegar a potência máxima de 16KW. Para ao SGDC,

165

a potência máxima gerada é de 10.5KW suficientes para atender à demanda nominal da carga útil de 8.5KW de consumo.

A massa total do SGDC na configuração de lançamento é estimada em 5831Kg sendo que a massa seca é de aproximadamente 2450Kg.

Apesar de o SGDC não ser o maior nem o mais potente satélite baseado na plataforma 4000 C4, o SGDC é considerado um satélite complexo devido a característica multi-spot de suas 3 antenas na banda Ka.

Antenas multi-spot além de ser um grande desafio em termos de complexidade de projeto, torna também o AIT mais complexo. Como exemplo de complexidade, os testes de RF dos repetidores de banda Ka, possuem mais de 800 combinações de caminhos diferentes que devem ser testados de forma a que todas as unidades, chaves, e guias de onde seja testadas pelo menos uma vez. Isso faz com que o sistema de teste automatizado e eficiente seja imprescindível.

Outro exemplo de complexidade das atividades de AIT é o processo de alinhamento das antenas multi-spot. Devido a grande quantidade de guias de ondas que interfaceiam com conjunto formado pelas cornetas alimentadoras das antenas multi-spot, o alinhamento desse conjunto é bem menos tolerante ao ajuste de alinhamento obrigando o alinhamento dos outros elementos da antena: refletor da antena, Mecanismo de Abertura e Posicionamento da Antena (ADPM) (do inglês: Antenna Deploy and Positioner Mechanism) e Mecanismo de Fixação e Liberação (HRM) (do inglês: Hold-down and Release Mechanism) serem referenciados pelas cornetas, processo esse que é diferente da antena mono-corneta onde o alinhamento é referenciado no posicionamento do ADPM seguindo a ordem normal de montagem dos elementos da antena.

Para mitigar essas dificuldades, as atividades críticas de AIT, são identificadas na fase inicial do projeto, e são periodicamente acompanhadas e avaliadas durante todos as etapas dos vários processos que envolvam os produtos e

166

processo dessas atividades críticas: projeto, fabricação, testes de aceitação, entrega para AIT, e integração no satélite, medida de alinhamento, entre outras. Todos os processos dos subsistemas e unidades críticas são mapeados e acompanhados pelo responsável de projeto mecânico.

Figura 4.10 Vista da SGDC na Configuração Normal de vôo.

Fonte: Adaptado de THALES (2012a)

4.3.4 O Processo de Engenharia de sistemas

Para garantir o tempo de entrega de 31 meses para um satélite de comunicações utilizando a plataforma Spacebus 4000 (THALES,2012a) a Thales aplica os conceitos da Engenharia Simultânea durante a fase de desenvolvimento inicial do projeto (THALES,2014). Internamente a fase inicial de desenvolvimento é chamada de fase Plateau e corresponde a fase 0, análise de missão e conceito. Com a assinatura do contrato, T0, a fase Plateau é iniciada e vai se estender até a fase C de detalhamento de projeto de sistema.

A Figura 4.11 mostra na parte superior as atividades de sistema que acontecem em Cannes e na parte inferior as atividades de subsistema que

167

para o Módulo Carga-útil (PM) acontece em Toulouse ao passo que para o Módulo de Serviço acontece em Cannes.

Figura 4.11 – Ciclo de Desenvolvimento de Satélites de Comunicações

Fonte: Adaptado de THALES (2014)

A Figura 4.12 mostra a Estrutura de Hierarquia da Produto (PBS) dos satélites baseados na plataforma Spacebus ao passo que a Figura 4.13 mostra o Estrutura da Divisão do Trabalho (WBS).

O pacote de trabalho AIT do Satélite (item 3 na Figura 4.13) é responsável pela montagem integração e teste do satélite e campanha de lançamento.

Note que o AIT do Satélite (item 3 na Figura 4.13) é responsável apenas pela integração dos produtos no nível hierárquico de sistema (produtos em destaque na Figura 4.13). O Módulo de Serviço (SM) e o Módulo Comunicações (CM) são entregues integrados e verificados pelos seus responsáveis, assim como os demais produtos no mesmo nível hierárquico.

168

Embora a responsabilidade do AIT do Satélite seja do RAIT, muitas das atividades são feitas pelos responsáveis dos respectivos produtos. Como exemplo, o Módulo de Comunicações (CM) é inteiramente testado pelos responsáveis do CM de Toulouse, assim como o fornecimento do GSE do CM para as atividades de AIT do Satélite. A mesma responsabilidade acontece com o produto Painel Solar (item 7.1 na Figura 4.13), porém nesse caso o GSE necessário é compartilhado: O trilho de sustentação é de responsabilidade do AIT do Satélite, mas os dispositivos utilizados para integração, abertura e fechamento são de responsabilidade do responsável pelo Painel Solar

Já outros produtos como por exemplo, os SADMs, HRMs e ADPMs (itens 7.2 e 7.3 na Figura 4.13), são integrados e testados sob responsabilidade do AIT do Satélite.

Figura 4.12 – Estrutura de Hierarquia de Produto (PBS) do Spacebus 4000 C com destaque para os GSEs

Fonte: Adaptado de THALES (2012a)

169

4.3.4.1 Fase Plateau

Dada a experiência adquirida, a fase Plateau é um processo controlado e recorrente com duração bem determinada de 9 meses a partir da assinatura do contrato (T0) para satélites baseados na plataforma Spacebus C. Durante essa fase são determinados os principais requisitos de sistema com o objetivo principal de (THALES,2014):

Dimensionar o satélite;
Levantar os diversos budgets de sistema como massa, potência, apontamento, ganhos etc;
Definir as arquiteturas mecânica, elétrica, térmica e de carga útil; · Especificar os subsistemas e unidades;
Definir a cadeia de fornecedores;
Fornecer as entradas para as revisões PDR e CDR de sistema; · Verificar as restrições dos meios de AIT.

O Plateau é marcado por um período de intenso trabalho de definição do

sistema com as seguintes características (THALES,2014):

Logística e organização dedicada; · Equipe integrada;
Equipe localizada sob mesmo teto para facilitar a interação.

Figura 4.13 – Estrutura da Divisão do Trabalho (WBS) do SGDC

Fonte: Adaptado de THALES (2014)

170

Figura 4.14 – Diagrama das atividades do Plateau no Ciclo de Vida do Satélite com destaque para as restrições dos meios de AIT

Fonte: Adaptado de THALES (2014)

Ao longo da fase Plateau, são gerados várias saídas como: desenhos de interfaces, modelos CAD e Projeto Técnico de Concepção (FTC) para validar as etapas de montagem.

Todas as definições ao longo do Plateau são congeladas em baselines e compartilhadas com seus contribuintes (stakeholders) a fim de verificar se todos os itens tais como entradas, evolução do trabalho, entre outros, estão coerentes. Ao final as saídas da fase Plateau são as entradas para as revisões PDR & CDR (THALES,2014).

A fase Plateau é marcada pela evolução das definições técnicas do satélite e é delimitada por 9 baselines programadas conforme mostrado na Tabela 4.6.

171

Tabela 4.6- Etapas do Processo de Plateau da Thales para Desenvolvimento de Satélites de Telecomunicações Baseados na Plataforma Spacebus.

Fonte: Adaptado de THALES (2014)

Durante a fase Plateau uma equipe de aproximadamente 10 profissionais experientes, chamado de “Plateau core time” ficam alocados em um mesmo espaço físico e são apoiados por até duas dezenas de profissionais do time de apoio, conforme pode ser visto nas lista abaixo:

Equipe de profissionais da fase Plateau core time e time de apoio:

Arquiteto Mecânico, Térmico e Propulsão (AMTP) (Líder do Plateau); · Arquiteto Elétrico – AEL;
Engenheiro Responsável pela Acomodação (IRA); · Responsável CAD (RCAO);

o Layout externo; o Layout interno; o Estrutura;

o Propulsão;

Responsável Técnico pela Carga-Útil (RTCU);

o Arquiteto Mecânico e Térmico do Repetidor (AMTR); o Líder do Layout de CAD do Repetidor;

o Engenheiro Responsável pelo Produto Antena (IRP Antenas);

o Engenheiro Responsável pelo Desenvolvimento das Antenas (IDEV);

172

Responsável pelo Controle Térmico de Sistema (RTS); o Responsável pelo Projeto Térmico;

o Responsável pelo Análise Térmica;

Responsável de Sistema de Análise Mecânica (RFM); o Responsável pela Estrutura (RMS);

o Responsável pela Cablagem DC (RMC); o Responsável pela Propulsão (RMP);

o Engenheiro Responsável pelos Mecanismos (IEP); o Responsáveis pelos Módulos: SM, CM, SS (RPM);

Arquiteto de Aniônica (AA);
Responsável Painel Solar e Mecanismos (IRP); · Responsável Técnico do Satélite (RT);
Engenheiro de Sistema (IS); · Responsável AIT (RAIT);
Gerente PMO (PM);

o Responsável pelo cronograma; o Responsável por logística;

Garantia de Produto (PA).

Durante a fase Plateau o time principal se reúne duas vezes por semana com objetivo de acompanhar as ações, definir as prioridades de curto prazo e compartilhar com todos os contribuintes o estado do progresso do trabalho.

Essas reuniões são feitas ao estilo Obeya, que são reuniões rápidas com duração não maior que 30 minutos feitas em pé em frente a um quadro onde são colocados as ações a cada arquitetura.

Reuniões específicas das arquiteturas são feitas semanalmente para garantir que as ações de sistemas sejam levadas aos subsistemas e vice-versa.

4.3.5 Fontes de Requisitos de GSE

Para o levantamento das necessidades e requisitos de GSE para um satélite como o SGDC foram analisados dezenas de documentos do programa. Tal qual esperado, nessa procura não foram localizados requisitos para GSE. Mas há de se considerar que no estágio de maturidade da plataforma Spacebus 4000 C bem como nos sucessivos sucessos dos seus satélites derivados, fica evidente que o produto final GSE atendeu e atende as necessidades impostas do AIT ao lançamento do satélite.

173

Dada as limitações desta análise pela impossibilidade de acesso a grande maioria dos documentos de projeto do GSE, esta análise será limitada nas seguintes fontes de requisitos para GSE:

Banco de dados do satélite; · Modelos CAD do satélite;
Requisitos de Testes;
Configuração de teste/atividade;
Requisitos de sistema e subsistema; · Plano de AIT;
Plano de Operações na Base de Lançamento; · Manual do Usuário do Lançador;
Outras fontes.

4.3.5.1 Banco de Dados do Satélite

O banco de dados do satélite é um produto de apoio que contém os parâmetros que descrevem e relacionam os diversos elementos que constitui o sistema. O banco de dados faz interface os diversos sistemas e usuários tais como:

Arquiteto Elétrico (AEL);
Arquiteto de Aviônica (AA);
Responsável Técnico pela Carga-Útil (RTCU); · Responsável pela Cablagem DC (RMC);
Responsável pelos testes de Aviônica;
Responsável pelo Simulador do Satélite do Segmento Solo.

O maior objetivo do banco de dados é manter todos esses parâmetros de projeto coesos, coerentes e acessíveis aos diversos usuários necessários nos processos de realização dos subsistemas, do sistema e durante o AIT e operação do satélite.

O banco de dados agrega e correlaciona diversas informações do sistemas tais como as listadas abaixo:

Definição de TM:

o Mnemonicos, descrição;

o Endereço, amostragem, formato etc; · Definição de TC:

174

o Mnemonicos, descrição;

o Código, parâmetros, links com TM; · Relação entre TM e TC;

Definição de pacotes de TM e TC;
Formato da TM de acordo com a fase: AIT, voo, etc; · Correlação de hardware e software de TC e TM;
Funções de transferência TM/TC; · Cálculo de parâmetros;
Condições de validade;
Endereçamento da cablagem de baixa frequência;
Parâmetros de ajuste de hardware (presença, configuração e posição dos sensores e atuadores, ganhos, alinhamento, etc);
Parâmetros diversos de missão (posição orbital, etc).

Cabe ao arquiteto elétrico, a responsabilidade da preparação e manutenção do banco de dados, que começa com definições de sistemas tais como código de equipamento, alocação de equipamento, alocação de circuitos, interligações de cablagem e alocações de canais de hardware etc. A responsabilidade de preparação e manutenção do banco de dados é compartilhada com outros agentes como o Arquiteto de Aviônica. Outros agentes são responsáveis por fornecerem as informações de entrada como por exemplos os responsáveis por cada um dos subsistemas e equipamentos.

Esse processo se estende ao longo do desenvolvimento dos subsistemas com as entradas de funções de transferência conforme os documentos de interface as-built, e somente é finalizado durante o AIT do satélite.

O banco de dados é uma fonte de entrada importante para o desenvolvimento do EGSE em especial o OCOE, mas é importante destacar que banco de dados faz interface com outros elementos que extrapolam os limites do EGSE, como sistema de teste do subsistema aviônica, o sistema de operações e controle de solo, a fabricação da cablagem.

Entradas para o Banco de dados do satélite:

ICD:

175

o ICD de Equipamento; o ICD de software;

Dados dos subsistemas:

o Recursos dos Equipamentos (canais, principal/secundário, ..); o Código TM e TC;

o Definição do plano de TM (definição dos pacotes/amostra); o Definição de parâmetros de controle térmico;

o Definição de Sequência de Eventos; · Endereçamento da cablagem;

Parâmetros de missão;

Os usuários do banco de dados do satélite:

Fabricação da cablagem;
Desenvolvimento e compilação do software embarcado: o Parâmetros de sistema;

o Parâmetros dos subsistemas; o Endereçamentos de hardware; o Mapa de telemetria;

o Mapa de telecomando; · Testes aviônica:

o Banco de Testes de aviônica: § Parâmetros de sistema;

Parâmetros dos subsistemas;
Definição e mapa das telemetrias;
Definição e mapa dos telecomandos; § Monitoração;
AIT do satélite: o OCOE:
Definição e mapa das telemetrias;
Definição e mapa dos telecomandos; § Monitoração;
Controle e Operação (Segmento Solo): o Simulador de Satélite
Definição das telemetrias;
Definição dos telecomandos;
Simulação de comportamento do satélite; § Atualização dos parâmetros de sistema;

o Operação em voo:

Definição das telemetrias;
Definição dos telecomandos; § Parâmetros de sistema;
Monitoração;

No OCOE, o banco de dados é a entrada para um banco de dados específico

chamado de Contexto do OCOE. No Contexto estão parâmetros exclusivos

176

para os testes como condições, lista de scripts disponíveis, valores limites e esperados, lista de comandos permitidos etc.

4.3.5.2 AIT

Durante o desenvolvimento dos projetos de satélites na Thales, na fases Plateau, o responsável de AIT é chamado para verificar viabilidade, disponibilidade e conflitos com relação ao AIT. Todo o processo de AIT é dividido em 4 processos distintos:

Definição;
Preparação; · Execução;
Coordenação.

A Figura 4.15 mostra a execução dos processos de AIT ao longo do cronograma do projeto.

O objetivos do processo de AIT são:

Demonstrar a viabilidade técnica e gerencial para execução do AIT;
Organizar e preparar procedimentos, meios e instalações para a execução do AIT;
Executar o AIT em acordo com os requisitos técnicos e dentro do prazo especificado;
Organizar, preparar e executar as atividades necessárias para lançamento do satélite dentro do cronograma.

Figura 4.15 – O processos de AIT versus Cronograma do projeto

Fonte:(THALES,2012b)

177

4.3.5.2.1 Definição de AIT

O processo de definição de AIT inicia junto com o Plateau e se estende até a CDR de sistema.

Os objetivos do processo de definição de AIT são:

Garantir que o satélite possa ser integrado e testado;
Identificar as restrições impostas pelo AIT e seus meios ao satélite;
Identificar e definir requisitos ao satélite de interface para garantir viabilidade e acessibilidade das atividades de AIT;
Propor e definir métodos de medida para garantir que a verificação atenda à precisão requisitada.

Durante a fase de definição de AIT são definidos (THALES,2012b):

Sequência de atividades de AIT;
Os meios de testes (GSE e Infraestrutura);
O dimensionamento dos recurso humanos necessários em termos de homem-hora e habilidades;
Cronograma de execução; · Plano de AIT.

O documento Plano de AIT é o documento principal de definição das atividades de AIT, e das atividades na base de lançamento. O plano de AIT é um documento que tem como entrada o Plano de Verificação, Requisitos de Testes e o contrato com o cliente. É o documento que descreve “o que”, “como”, “quando” e “quem” das atividades de AIT.

No plano de AIT estão listados os meios necessários para as atividades i.e.,

GSE e infraestrutura (THALES,2012b).

Embora o plano de AIT liste o GSE necessário ele é a saída de processo de definição do AIT e o maior objetivo é demonstrar ao cliente a viabilidade do AIT.

A fim de demonstrar a viabilidade do plano de AIT, podem ser identificado que algumas das atividades necessitem documento de análise de risco e documento de configuração e interface (FTO). Esses documentos são

178

preparados pelo PMO e entregues em cronograma determinado na fase de definição de AIT.

O fato de o SGDC ser baseado em uma plataforma recorrente, pouco em termos de GSE foi feito de específico para o satélite SGDC. A seguir é listado o GSE desenvolvido para o SGDC:

Cargas de RF para testes em modo conduzido – CALA; · Proteções das TWTA Irradiadas;
Reforço no carrinho de integração (dolly); · SCOE do SST;
SCOE do CM;
Unidades de carregamento das chaves de segurança;

É importante observar que para o GSE recorrente, cabe ao responsável de

cada elemento do GSE demonstrar que o equipamento atende aos requisitos impostos.

4.3.5.2.2 Entradas do Processo de Preparação de AIT

No processo de preparação de AIT para a plataforma Spacebus há um documento interno que define em termos gerais quais são os documentos de entrada e estabelece os prazo para cada documento de entrada em relação ao cronograma das revisões TRR e de marcos das atividade de AIT.

Esse documento define pacotes de dados e documentos bem específicos como o documento de Requisito de Alinhamento dos ADPM, que deve ser disponibilizado em duas versões: 2 meses antes da TRR da fase de montagem do ADPM sem as posições definidas e uma segunda versão 2 meses antes do início da atividade em versão final.

O PMO é responsável de fornecer antecipadamente os seguintes documentos para todos os testes e operações planejadas durante AIT:

Documento de Requisito de Testes · Configuração de Teste;
Fichas Técnicas de Concepção (FTC) · Banco de Dados do Satélite;

179

Configuração e Interface (FTO).
Modelo 3D das configurações do satélite; · Requisitos de Testes;
Documentos de Análise de Risco.

4.3.5.2.3 Preparação de AIT

Dependendo da fase e de o quanto a atividade é considerada recorrente, a

preparação de uma atividade de AIT se inicia em média 6 meses antes do início da atividade. Esse tempo pode ser maior caso seja necessários desenvolver novos GSEs ou se envolve atividades que não há procedimento disponível.

As TRR de uma atividade de AIT é de responsabilidade do RAIT e normalmente é feita entre 1 e 2 meses antes do início da atividade. Um documento de descrição desse processo estabelece exatamente quais são as condições para que se possa realizar uma TRR assim como os critérios de aprovação da mesma.

O objetivo da TRR é demostrar

o Verificara a configuração de todos os produtos;

o Verificar disponibilidade e validade dos meios de testes: GSE e infraestrutura;

o Garantir que o elemento em revisão está pronto para prosseguir;

o Avaliar os objetivos, métodos e procedimentos, escopo e segurança da atividades planejadas;

o Verificar se os recursos estão disponíveis;

o Verificar a rastreabilidade das atividades planejadas e se os requisitos estão formalmente aprovados pelo arquiteto.

4.3.5.2.4 Sequência de AIT de Satélite de Comunicações

A sequência de AIT dos satélites baseado na plataforma Spacebus 4000 C4 é bastante optimizada com o objetivo principal de reduzir o tempo de AIT. A optimização da sequência de AIT é fundamental para não somente a redução

180

do tempo mas para redução de custos e de riscos relacionados as atividades repetidas.

A sequência do AIT é iniciada com a entrega do SM e do PM, integrados e testados para o “mating”, acoplamentos entre os dois módulos, refletindo o WBS do SGDC da Figura 4.13. O AIT do SM não é tratado no plano de AIT do satélite mas sim em documento separado. A razão disso é que o SM é totalmente recorrente podendo ser otimizado ao máximo já que são utilizados procedimentos genéricos para a plataforma.

Por conta da sequência optimizada, alguns acelerômetros, para os testes de

vibração, são instalados no interior do satélite durante as fases iniciais da montagem do SM e não são removidos após o teste de vibração para evitar a desmontagem do satélite. Essa decisão faz com que esses acelerômetros bem como sua fixação e cablagem sejam feitos para atender ao ambiente vácuo-térmico e de voo.

Um exemplo dessa optimização é a chamada “sequência inversa” dos testes ambientais para satélites de telecomunicações. A sequência clássica de AIT é estabelecida para ser o mais próximo possível da sequência real em voo, ou seja, na sequência convencional, o teste de vibração e acústico precedem o teste de vácuo-térmico. Com o objetivo de optimização da sequência de integração, e devido a necessidade de que o satélite deve estar na configuração de lançamento para os teste de vibração e acústico, ou seja com todos seus elementos montados, incluindo os elementos externos como: painéis solares, antenas e refletores, ao passo que o teste vácuo-térmico esses mesmos elementos não podem estar montados devido a limitações da câmara TVT e simplificação da configuração do satélite, esses testes são invertidos na execução, conforme pode ser vista na Figura 4.16.

A própria sequência de AIT também impõe requisitos ao GSE. Um exemplo disso é a necessidade de testes de performance dos repetidores em ambiente vácuo-térmico que demanda que as cargas de RF sejam propícias ao ambiente de vácuo e refrigeradas a água dentro da câmara vácuo-térmica. Por conta

181

desses requisitos, somado à quantidade de repetidores e antenas multi-spot, essas cargas ficam grandes e pesadas, alterando a configuração do satélite em teste, sem a torre, antenas e mecanismos da face terra, devido a uma interferência mecânica com as cargas de RF do EGSE, chamadas de CALAS.

Outro exemplo de optimização da sequência de AIT é o fato de os testes irradiados da carga útil, somente são feitos após os testes ambientais, quanto as antenas estão montadas.

E por último, como exemplo de otimização da sequência de integração é o teste de vazamento global do sistema de propulsão somente é feito nas preparações finais para transporte à base de lançamento, utilizando o próprio container de transporte.

182

Figura 4.16 – Sequência Inversa de AIT para Satélites de Telecomunicações.

Fonte: Adaptado de THALES (2012b)

Todos os testes são executados automaticamente. Para isso é necessário que seja desenvolvido um script. O script deve executar o teste especificado no requisito de teste utilizando os telecomandos e telemetrias especificados em um documento chamado DTD.

4.3.5.2.5 Lançamento

Ao final do AIT, o satélite é preparado e colocado no container para transporte

à base de lançamentos. O transporte à base de lançamento é feito com satélite na configuração praticamente de voo, faltando apenas combustível e remoção de protetores.

183

O plano de AIT inicialmente apresentado na PDR, mantinha aberto a 3 lançadores possíveis: Arine 5, Proton e Zenit. Na CDR, foi apresentado o novo plano de AIT com a definição do Ariane 5 como lançador.

O documento Ariane 5 User’s Manual Spacecraft interfaces Issue 5 Revision 1

(ARIANE,2011) , define vários requisitos para o GSE.

Para o EGSE o documento define apenas 2 tipos: OCOE e COTE (Check-Out Test Equipment).

O OCOE que deve fica permanentemente instalado na sala de controle PPF durante todas as fases da campanha de lançamento e interfacear como COTE conforme rede de dados mostrado na Figura 4.20.

O COTE deve prover ao satélite monitoramento, controle, energia elétrica e circuitos de proteção. O COTE deve acompanhar o satélite durante as atividades de preparação PPF, HPF e BAF. Nas atividades de lançamento o COTE fica instalado na plataforma de lançamento.

O manual também limita fisicamente o COTE em 1m de largura por 0.8 de profundidade e com peso máximo de 800Kg.

O documento ainda especifica requisitos ambientais paras os equipamentos

instalados no COTE conforme Figura 4.17.

Figura 4.17 – Especificação de vibração para COTE durante lançamento

Fonte: Adaptado de ARIANE (2011)

184

Figura 4.18 – Interface umbilical com o satélite acoplado ao lançador e EGSE

Fonte: Adaptado de ARIANE (2011)

185

Figura 4.19 – Configuração de controle remoto do satélite durante campanha de lançamento

Fonte: Adaptado de ARIANE (2011)

186

Figura 4.20 – Configuração típica da rede de dados na base de lançamentos

Fonte: ARIANE (2011)

4.3.5.3 Outras Fontes de Requisitos para GSE

Muitas das fontes de requisitos tanto para o satélite como para o GSE são fontes externas tais como normas internacionais aplicáveis (THALES,2015b):

MILSTD-1576 Electro-explosive subsystems, electrically initiated, Design requirements and test methods.
MILSTD-1553B Aircraft Internal Time Division Command/Response Multiplex Data Bus
MILHDBK-1553 Validation Test Plan for the Digital Time Division/Response Multiplex Data Bus Remote Terminal.

4.3.6 Desenvolvimento de GSE

Uma das vantagens que a Thales apresenta orgulhosamente em seu material de divulgação é o fato de ter controle sobre seu “supply chain” mantendo

187

contratos de longo prazo com seus fornecedores e utilizando ao máximo produtos recorrentes (THALES,2012a).

A recorrência é bastante perceptível no GSE que o mesmo entre satélites de uma mesma plataforma e possuem muitas heranças com o GSE de plataformas anteriores.

Outra grande vantagem que a Thales apresenta é o fato de desenvolver soluções “in house” para praticamente todos os processos do ciclo de desenvolvimento.

Devido ao fato que a plataforma Spacebus 4000 C já estar com mais de 10

anos desde seu debute, fica difícil fazer uma análise completa sobre o desenvolvimento do GSE já que a grande maioria dos elementos já estão desenvolvidas (THALES,2012a).

Os esforços de desenvolvimento no GSE para novas missões, como é o caso

do SGDC, estão mais focados no desenvolvimento de produtos específicos da missão, ou devido a alguma melhorai como resultado do processo de Retorno de Experiência – REX de programas anteriores na empresa.

Após a fase Plateau, e com a baselines disponíveis, a equipe de AIT tem

acesso direto aos modelos do satélite incluindo variações de configurações para cada uma das etapas prevista do processo de AIT.

Com os modelos do satélite disponíveis e com os documentos de Ficha Técnica das Ferramentas e Interfaces – FTO (sigla em francês de Fiche Technique d’Outillage) cada um dos responsáveis pode então dar início aos preparativos da fase de AIT sob sua responsabilidade, sem risco de má interpretação de requisitos, já que a baseline dos modelos em CAD, o FTO e FTC (sigla em francês de Fiche Technique de Conception) estão disponíveis.

4.3.6.1 EGSE

Na Thales de Cannes, dois departamentos dividem responsabilidades pelo

EGSE do SM e do satélite: CC-GR e CC-AIT. O departamento CC-GR é

188

responsável pelo arquitetura, desenvolvimento e acompanhamento junto com fornecedor, ao passo que o departamento CC-AIT é responsável pela gestão da “frota” de EGSEs, i.e. manutenção, verificação de calibração e logística.

O EGSE do módulo de comunicação – CM fica sob responsabilidade da Thales

de Toulouse, que também é responsável pelo desenvolvimento e AIT do CM.

A arquitetura do EGSE do SGDC permite que os testes no CM sejam independentes das atividades da aviônica, com algumas exceções devido as características do satélite e a limitações de potência do EGSE.

Essa independência dá bastante flexibilidade para que as ferramentas de

testes sejam optimizadas a atendam a necessidades específicas de cada subsistema. Outra vantagem é que os testes de aviônica e na carga útil podem ser feitos em paralelo, salvo alguns conflitos de configuração do satélite.

4.3.6.1.1.1EGSE

Em paralelo ao desenvolvimento da plataforma spacebus C, foi desenvolvido a

aviônica 4000.

O EGSE de sistema dos satélites de telecomunicações na Thales

Na Thales, o desenvolvimento do EGSE de sistema começa pelo

desenvolvimento dos EGSE de subsistemas. O EGSE é divido conforme o WBS e sendo assim para um satélite telecomunicações como o SGDC essa divisão resulta em um EGSE de Aviônica e um EGSE de carga útil. Cabe uma observação que o subsistema TCR é parte da carga útil para os satélites telecomunicações da Thales.

O EGSE de aviônica possui várias comonalidades com o Avionics Test Bench – ATB e isso vantagens:

Redução do esforço de desenvolvimento;
Diminuição da ocorrência de bugs na fase de AIT; · Utilização do mesmo banco de dados;
Comparação de resultados entre os testes em bancada com os testes integrado;

189

O desenvolvimento do ATB leva em conta a utilização em 3 momentos distintos do ciclo de vido do satélite: Desenvolvimento e teste do subsistema de aviônica, Testes de sistema da Aviônica e operação da plataforma após lançamento.

Para atingir esses objetivos, o ATB é concebido tendo em vista 3 famílias:

ATB numérico;
ATB híbrido com OBC;
ATB híbrido com simulador OBC

ATB numérico simula OBSW em um emulador do computador de bordo e

possui 3 versões de validação:

Versão para validação da aviônica (e-ATB): · Versão para validação de AIT (SIM-AIT),
Versão para validação de operação por meio do Simulador Dinâmico do Satélite (DSS).

4.4 Programa PMM

A Plataforma Multimissão – PMM é a plataforma genérica para satélite de até 500 Kg atualmente em desenvolvimento no INPE e com previsão de lançamento do seu primeiro satélite em 2018.

Tabela 4.7 – Características da PMM

Massa carga útil

Altitude:

Órbita

Inclinação

Lançadores considerados

Até 280 Kg

entre 600 e 1200 km

SSO com horário de cruzamento do equador

entre 6-8 AM, 10 AM-2 PM, e 4-6 PM

próximas das equatoriais até 15° e as

DNEPR, PSLV, Rockot, Taurus e Vega.

Fonte: (BOGOSSIAN,2012)

4.4.1 Satélite Amazonia-1

O Amazonia-1 será o primeiro satélite baseado na Plataforma Multimissão (PMM) atualmente em desenvolvimento no INPE.

190

O Amazonia-1 tem como missão prover dados para o monitoramento ambiental e dar continuidade e aperfeiçoamento do sistema de detecção em tempo real (DETER) do desflorestamento no Brasil (AEB,2012).

O satélite será provido de um imaginador óptico de visada larga – AWFI

(tradução livre de Advanced Wide Field Imager) dotado de 3 bandas espectrais visíveis (VIS) e 1 banda em infravermelho próximo (NIR), capaz de observar uma faixa de 720 Km com 40 m de resolução espacial (INPE,2017).

A Figura 4.21 mostra a concepção artística do Amazonia-1.

O satélite é dotado de um módulo de serviço – SM comum baseado na

plataforma PMM, que abriga os subsistemas de serviço essenciais tais como:

Subsistema de suprimento de potência e painéis solares; · Subsistema de controle térmico;
Subsistema de propulsão;
Subsistema de telemetria, rastreio e comando (TT&C);
Subsistemas de atitude e controle de órbita e gerenciamento de dados (ACDH) divididos em:

o Sistema de atitude e controle de órbita (AOCS);

o Subsistema de gerenciamento de dados a bordo (OBDH);

O módulo de carga útil – PM é projetado para dar suporte e acomodar os

subsistemas de carga útil, que no caso do Amazonia-1 é formado pelo AWFI.

Figura 4.21 – Concepção Artística do Satélite AMAZONIA-1

Fonte: (AMAZONIA,2011)

191

Figura 4.22 – Segmento Espacial do WBS do AMAZONIA-1

Fonte: (AMAZONIA,2011a)

4.4.2 EGSE Amazônia

De acordo com documento de especificação do EGSE para o satélite

Amazonia-1 (INPE,2015a) o EGSE deve ser formado de um conjunto de equipamentos de suporte elétrico, integrado como um sistema de teste que

192

forneça toda a funcionalidades necessária para a integração elétrica e para os testes elétricos do satélite, desde a integração de potência ao lançamento.

O EGSE do Amazonia-1 é composto do OCOE, TBU, SCOEs e a rede de dados que interliga seus elementos. A Figura 4.23 mostra um diagrama de blocos genérico simplificado do EGSE, sem detalhes de contexto de operação.

A EGSE do Amazonia-1

Figura 4.23 – Diagrama em blocos do EGSE Amazonia-1 com destaque ao SCS SCOE

Fonte: Adaptado de AMAZONIA (2015a)

193

Tabela 4.8 – Descrição Simplificada dos Elemento do EGSE do Satélite Amazonia-1

Fonte: Adaptado de AMAZONIA (2015a)

Figura 4.24 – Diagrama de contexto EGSE Amazônia 1 durante AIT

Fonte: Adaptado de AMAZONIA (2015a)

194

4.4.3 SCS SCOE

O SCS SCOE fornece a interface entre EGSE com o satélite durante o AIT para ligar e desligar o satélite, monitorar sinais vitais presentes nos conectores umbilical e externos, e simular sinais para a operação do satélite como: sinal de separação com o lançador, sinais de abertura dos painéis solares etc. Sinais dedicados aos teste e operação do AOCS não passam pelo SCS SCOE.

Um diagrama de contexto do SCS SCOE durante as atividades de AIT é mostrando na Figura 4.25.

Os requisitos funcionais do SCS SCOE são listados abaixo:

Ser capaz de validar as interfaces com o Satélite, com auxílio de um simulador de interface de satélite (SIS);
O SIS deve verificar os sinais gerados pelo SCS SCOE;
O SIS deve permitir a verificação no SCS SCOE de todas os sinais do satélite;
Medir a resistência de aterramento do equipamento durante a operação mecânica e integração elétrica;
Medir a resistência dos dispositivos pirotécnicos;
Monitorar os sinais do satélite presentes nos conectores de separação pelo cabo umbilical;
Enviar pulsos de comandos para ligar/desligar subsistemas selecionados do módulo de serviço;
Monitorar as telemetrias de alimentação provenientes do PSS durante a fase de integração de potência;
Fornecer interface que permita conectar e desconectar os canais SAS do PSS SCOE para alimentar o satélite através do conector umbilical; 10.Fornecer interface que permita conectar e desconectar os canais SAS

do PSS SCOE para alimentar o satélite através dos SADAs; 11.Redirecionar os sinais presentes no cabo umbilical para os demais

elementos do EGSE;

12.Fornecer pulso de comando e monitorar estado para abertura do conector umbilical;

13.Ativar, para fins de teste, nos modos manual, local e remoto, quando necessário, os sinais de separação do satélite com o lançador;

14.Ativar, para fins de teste, nos modos manual, local e remoto, quando necessário, os sinais de simulação de abertura SAG;

15.Fornecer o sinal para indicar ao controlador do lançador, durante os testes finais na torre de lançamento, o status da conexão de energia do SAS para o satélite;

195

16.Fornecer o sinal para indicar ao controlador do lançador, durante os testes finais na torre de lançamento, o status de conexão do conector umbilical;

17.Indicar, com uma lâmpada rotativa vermelha, o estado ligado/desligado do satélite;

18.Indicar com uma lâmpada rotativa azul o estado de irradiação de RF do satélite;

19.Enviar dados de monitoramento para o OCOE em intervalos programáveis ou quando um mudanças estado do sinal de “go” (dentro da faixa válida) para “no go” (fora da faixa válida) e vice-versa;

20.Enviar mensagem para o OCOR para cada operação executada localmente ou remotamente;

21.Permitir o controle remoto de pelo menos as seguintes funções: a. Configuração do SCS SCOE;

b. Envio de pulso de comando por fio;
Simulação dos sinais de separação do satélite; d. Simulação dos sinais de abertura do SAG;
e. Conexão/desconexão das linhas de alimentação do SAS ao umbilical;
Controle das lâmpadas de indicação de estado do satélite; 22.Fornecer o equipamentos necessário para desempenhar as funções

descritas acima, nos modos de operação manual, local e remoto; 23.Fornecer os equipamentos e acessórios necessários para possibilitar a

conexão dos equipamentos de teste à unidades do satélite durante integração e testes especiais (BOBs e cabos de interface, multímetros, osciloscópio);

24.Registrar os envios de de pulso de comandos por fio; 25.Registrar os sinais de monitoração;

26.Imprimir dados de teste a pedido usuário local.

196

Figura 4.25 – Diagrama de contexto do SCS SCOE do Amazônia 1 durante AIT

Fonte: Adaptado de AMAZONIA (2015a)

O Equipamento Específico de Teste (SCOE) do Subsistema Circuitaria (SCS) é o elemento que faz interface direta com o satélite através das seguintes interfaces:

Conector de separação para prover ao satélite por meio do Simulador de Painel Solar – SAS (tradução de Solar Array Simulator);
Conector de separação para comando enviado por fio e sinais vitais de monitoração;
Conectores Superficiais (tradução de Skin Conectors) par simulação de simular a separação do satélite-Lançador;
SADA para simular sensores e a abertura do Gerador Solar (SAG);
SADA para transferir potencia do SAS para a PCDU para verificar a interface do SAG com o SADA;
Conectores das unidades quando houver necessidade durante AIT de acessar sinais via BOB (Break-Out-Box).

197

Além das interfaces com o satélite o SCS SCOE deve fazer interface com os seguintes elementos do EGSE:

OBDH SCOE:

o Telemetria:

Interface física: RS-422;
Dado: PCM /NRZ-L síncrono;
Codificação: RS + Convolução ESA-PSS-04-106 (CCSDS ,1988);
Taxa de dados: 1280, 960, 768, 640, 480, 320, 240, 192, 160, 128, 96, 64, 48, 32, 16, 4 kbps.

o Telecomando:

Interface física: RS-422;
Dado: PCM /NRZ-L síncrono;
Codificação: RS + Convolução ESA-PSS-04-107 (CCSDS ,1988);
Taxa de dados: 4 kbps.

Figura 4.26 – Diagrama de Contexto do EGSE Amazônia 1 Durante Lançamento

Fonte: Adaptado de AMAZONIA (2015a)

198

5 O Guia de Desenvolvimento de GSE Proposto

5.1 Objetivos

O objetivo deste capítulo é apresentar um guia para a engenharia de sistemas simultaneamente aplicada ao produto espacial, seu processo de AIT e ao Equipamento de Suporte em Solo – GSE (sigla do inglês: Ground Support Equipment) necessários ao processo de AIT.

O objetivo deste guia é auxiliar as organizações desenvolvedoras envolvidas nos projetos espaciais no desenvolvimento dos elementos do GSE que atenda as necessidades específicas das atividades de AIT de um produto espacial.

Para atingir esse objetivo, este guia irá correlacionar os desenvolvimentos do GSE, do processo de AIT e do produto espacial com o objetivo final de sistematizar o desenvolvimento do GSE.

5.2 Introdução

Tradicionalmente, no desenvolvimento de um sistema, o processo de

engenharia de sistemas é recursivamente aplicado aos seus elementos e subsistemas resultantes da decomposição sistema.

O processo de engenharia de sistemas é iniciado com a análise dos stakeholders, passando então para a análise de requisitos. Interativamente e progressivamente ao processo de análise de requisitos são aplicados os processos de análise funcional e análise de implementação onde então outros subsistemas são identificados e seus requisitos especificados (ISO/IEC15288:2008). Dessa forma, a decomposição do sistema em subsistemas, os subsistemas em outros produtos e assim por diante, é recursivamente aplicada até que um produto possa ser comprado, desenvolvido ou reutilizado, unicamente por meio da especificação de seus requisitos.

199

Durante a análise de requisitos, restrições são levantadas para o produto de interesse a partir da análise dos processos de seu ciclo de vida. Os processos do ciclo de vida, são analisados também como elementos decompostos do sistema, onde então são identificados os produtos de apoio para que deem suporte ao produto (de interesse) durante os processos do ciclo de vida (IEEE-Std-1220:2005).

Ainda de acordo com a norma IEEE-Std-1220:2005, no desenvolvimento de um produto de apoio, é aplicada a recursividade do processo de engenharia de sistemas, fazendo com que o produto de apoio seja considerado o produto de interesse no contexto do seu desenvolvimento.

Para os produtos de apoio, essa forma tradicional de desenvolvimento não consegue capturar adequadamente a totalidade dos requisitos do produto de apoio no momento do decomposição do elemento acima na hierarquia do sistema, como acontece em um sistema de interesse, devido ao fato de o design interno do produto de apoio depender do design interno do produto de interesse (HALLIGAN,2012). Essa dependência do design faz com que a decomposição de um elemento em produtos baseada apenas na especificação de requisitos, embora seja válida conceitualmente mostra-se impraticável no desenvolvimento dos produtos de apoio no momento de sua decomposição, sendo assim responsável por atrasos e não-conformidades somente identificadas durante a execução do processo de AIT .

Com o objetivo final de desenvolver os elementos do GSE, i.e., os produtos de apoio para as atividades de AIT, o guia proposto nesta dissertação integra o desenvolvimento do produto espacial, seus processos do ciclo de vida em especial o processo de AIT, e os produtos de apoio necessários a dar suporte ao produto de interesse durante o processo de AIT.

O guia proposto nesta dissertação utiliza-se dos métodos e processos de Engenharia de Sistemas das principais normas e manuais de Engenharia de Sistemas internacionais publicadas pelas seguintes organizações e amplamente utilizadas na indústria aeroespacial.

200

European Cooperation On Space Standardization – ECSS, · International Organization for Standardization – IS0;
Institute of Electrical and Electronics Engineers – IEEE; · International Council On System Engineeringi – INCOSE; · National Aeronautics And Space Administration – NASA;

O guia propõe ainda, baseado no framework de Visão Total de Loureiro (1999), aplicar o processo de engenharia de sistemas simultaneamente ao produto de interesse, aos seus processos do ciclo de vida (incluindo os produtos de apoio necessários) e às organizações desenvolvedoras a fim de estabelecer as interfaces e funções organizacionais necessárias a possibilitar o desenvolvimento do sistema.

Este guia de desenvolvimento tem por objetivo final desenvolver os produtos de apoio necessários ao processo de integração e testes (AIT), que é apenas uma parte do processo dos ciclo de vida de um produto espacial. Embora a metodologia utilizada possa ser aplicada a quaisquer produtos de apoio de qualquer processo do ciclo de vida, este guia irá restringir-se a apenas aos produtos de apoio denominados de GSE (sigla do inglês Ground Support Equipment) necessários para as atividades de AIT de um produto espacial. Para isso o guia proposto correlaciona o desenvolvimento da tríade de elementos: o sistema espacial, seu processo de AIT, e o GSE necessário ao processo de AIT.

5.3 Fundamentação do Guia

O guia proposto nesta dissertação é um guia de desenvolvimento de produtos de apoio, em especial o GSE, para o processo de AIT de um produto espacial.

O processo de AIT pode ser definido como “…uma sequência de eventos logicamente inter-relacionados, cujo propósito é obter um alto grau de confiança..” (SILVA JR,2011), isto é, é um conjunto de atividades integradas que transforma a entrada: subsistemas, unidades, e materiais em uma saída: produto espacial integrado e verificado conforme observado na Figura 5.1.

201

Como todo processo, o processo de AIT necessita de mecanismos de apoio. Dentre esses mecanismos estão as ferramentas, instalações, recursos humanos e técnicas necessários ao processo de AIT.

Embora o objetivo final deste guia seja o desenvolvimento do GSE, o GSE não

pode ser desenvolvido isoladamente apenas com a aplicação do processo de engenharia sem que seja analisado o processo de AIT que o demanda, bem como o produto espacial para o qual se aplica o processo de AIT e cujo design está intrinsicamente conectado ao GSE conforme observado na Seção 5.2.

Figura 5.1 – IDEF0 do Processo de AIT

a) IDEF0 de um processo b) IDEF0 do processo de AIT Fonte: Adaptado de ISO/IEC-TR-19760 (2003)

De acordo com a norma ISO/IEC-TR-19760:2003, a organização responsável

pela fase do ciclo de vida de um produto também é responsável por garantir que todo produto de apoio necessário esteja disponível para a realização da fase do ciclo de vida. Alguns produtos de apoio podem estar dentro ou fora do escopo do projeto conforme observado na Figura 5.2.

Produtos de apoio dentro do escopo do projeto são desenvolvidos internamente ou adquiridos conforme o plano de desenvolvimento do processo de AIT. Por outro lado produtos de apoio fora do escopo do projeto são demandados a outras organizações.

202

Figura 5.2 – Relação entre Escopo de Interesse e Controle do Projeto

Fonte: Adaptado de ISO/IEC-TR-19760 (2003)

O guia proposto nesta dissertação é suportado por quatro fundamentos básicos:

Engenharia de sistemas: Aplicar os princípios e processos de

engenharia de sistemas das normas internacionais de engenharia de sistemas e engenharia espacial;

Abordagem de Sistemas Abertos: Aplicar a abordagem de Sistemas Abertos (tradução do termo em inglês “Open System”) de forma a facilitar mudanças e melhorias;
Desenvolvimento Simultâneo: Desenvolver simultaneamente a tríade de elementos do sistema: o produto espacial, seu processo de AIT e o GSE necessário, incluindo seus produtos decompostos;
Interfaces organizacionais: Identificar e correlacionar as interfaces de design entre os projetos e suas correspondentes organizações desenvolvedoras.

203

5.3.1 Engenharia de sistemas

O guia proposto nesta dissertação reforça a necessidade de aplicação dos requisitos, métodos e processos de engenharia de sistemas de acordo com as principais normas internacionais de engenharia de sistemas e de engenharia espacial:

IEEE-Std-1220:2005 – Aplicação e Gerenciamento do Processo de Engenharia de

sistemas;

ISO/IEC15288:2008 – Processos do ciclo de vida de sistema – Engenharia de

sistemas e Software;

ISO/IEC-TR-19760:2003 – Guia de Aplicação da ISO/IEC 15288

ECSS-E-ST-10C:2009 – Requisitos Gerais de Engenharia de Sistemas em

Engenharia Espacial;

ECSS-E-ST-10-02C:2009 – Verificação em Engenharia Espacial

ECSS-E-ST-10-03C:2012 – Testes em Engenharia Espacial.

As normas ECSS de engenharia de sistemas têm uma grande vantagem em relação as normas IEEE ou ISO por focarem um domínio específico de produtos espaciais, e portanto são diretamente aplicáveis ao desenvolvimento de produtos espaciais. Porém para desenvolvimentos de produtos de apoio, incluindo simuladores, modelos e GSE, uma abordagem mais flexível pode ser vantajosa.

Durante o desenvolvimento de um sistema espacial, o processo de engenharia de sistemas é aplicado a cada nível na estrutura hierárquica do sistema para levantar requisitos e decompor o sistema em subsistemas (produtos). Requisitos são então decompostos e alocados aos produtos de nível abaixo da estrutura hierárquica do sistema. Dessa forma, progressivamente, o processo de engenharia de sistemas é aplicado recursivamente aos produtos decompostos com o objetivo de atender a requisitos operacionais do sistema.

Por outro lado, durante a realização do sistema, os produtos e elementos dos níveis mais baixos da estrutura hierárquica do sistema são integrados e

204

verificados de forma a garantir que os requisitos sejam satisfeitos recursivamente até o nível hierárquico mais alto do sistema.

Durante o processo de realização, é necessário o desenvolvimento de métodos, processos e ferramentas para atingir o objetivo final desejado: o sistema completamente integrado e com comprovação de atendimento aos requisitos especificados nas fases iniciais de seu desenvolvimento. Os métodos, processos e ferramentas necessários são produtos de apoio do processo de AIT.

O presente guia utiliza-se dos processos de engenharia de sistemas

detalhadamente descritos nas normas IEEE-Std-1220:2005, ISO/IEC15288:2008, e ECSS-E-ST-10C:2009 que são aplicados integralmente no desenvolvimento dos produtos e elementos que compõe o sistema.

Os processos do ciclo de vida, são tratados nesta dissertação como elementos

do sistema a serem desenvolvidos, conforme o faz a norma IEEE-Std-1220:2005 e apresentado na Seção 2.3.3 desta dissertação.

O guia proposto nesta dissertação aplica os métodos e processos de engenharia de sistemas de forma simultânea ao produto espacial, seus processos do ciclo de vida em especial aos processos de AIT e seus elementos decompostos, incluindo os sistemas de apoio identificados nos processos de AIT: o GSE e seus elementos.

O objetivo final deste guia é sistematizar o desenvolvimento do GSE, cuja

funcionalidade é intrinsicamente dependente da solução de AIT e da solução de design do sistema espacial.

As normas de engenharia de sistemas recomendadas neste guia, tais como ISO/IEC15288:2008, IEEE-Std-1220:2005 e ECSS-E-ST-10C:2009, embora não possuam diretivas de aplicação de engenharia simultânea, suportam e recomendam a sua aplicação conforme pode ser observado nos fragmentos abaixo:

205

“….. Os processos do ciclo de vida desta norma internacional podem ser aplicados simultaneamente, iterativamente e recursivamente a um sistema e seus elementos.”(ISO / IEC15288: 2008).

“A empresa ou projeto pode integrar o design simultâneo de produtos e seus processos de ciclo de vida relacionados. A engenharia simultânea pode integrar o desenvolvimento do produto e do processo para garantir que o produto seja possível de ser fabricado, utilizável e mantido… “(IEEE-Std-1220: 2005);

“O Processo de Engenharia de Sistemas deve descrever também 1. o(s) método(s) e processo(s) considerado(s) para as atividades de engenharia (por exemplo, engenharia simultânea, análise ou loops de iteração) …” (ECSS-E-ST-10C: 2009)

Este guia reforça a necessidade de desenvolvimento simultâneo e correlaciona os projetos do produto espacial, seus processos do ciclo de vida, em especial o AIT, e o GSE necessário para o processo de AIT. Como esses três elementos são desenvolvidos em organizações diferentes, mesmo que essas organizações sejam departamentos dentro de uma mesma organização ou empresa, o guia tenta correlacionar os produtos de apoio de design de cada projeto.

Ao correlacionar o desenvolvimento simultâneo dos três elementos do sistema (o produto espacial, o processo de AIT e o GSE) as interfaces entre esses três projetos e por consequência as interfaces entre as organizações desenvolvedoras se tornam o relevantes para este guia.

Figura 5.3 – Estrutura hierárquica do Sistema e a Definição de seus Processos do Ciclo de Vida

Fonte: Adaptado de IEEE-Std-1220 (2005)

206

5.3.1.1 Modelo de Desenvolvimento

Normalmente produtos espaciais seguem o modelo “Vê” para desenvolvimento por ser o mais adequado para decomposição e desenvolvimento dos seus produtos derivados na estrutura hierárquica do sistema.

O lado esquerdo do modelo “Vê” destaca a decomposição hierárquica do

sistema ao passo que o lado direito destaca a necessidade de verificações sucessivas a longo de sua integração. A parte central do modelo Vê é a evolução das baselines de requisitos para definição dos componentes que irão integrar o sistema final.

O modelo “Vê” assume uma visão “top-down” do sistema, na qual a cada

decomposição do sistema em subsistemas (produtos), estes possam ser completamente especificados seguindo o processo de engenharia de sistemas.

A visão “top-down” do modelo “Vê” não permite capturar a totalidade dos requisitos dos elementos dos processos do ciclo de vida e dos produtos de apoio pelo fato de o design destes depender do design e da solução do produto de interesse conforme observado na Seção 5.2.

Embora o produto espacial siga o modelo “Vê” para seu desenvolvimento isso não impede que os outros elementos do sistema como os processos do ciclo de vida do produto de interesse e os produtos de apoio possam ser desenvolvidos em outros modelos mais flexíveis e adaptativos que o modelo “Vê” tais como o modelo incremental e o modelo evolutivo de desenvolvimento.

O modelo incremental é caracterizado pela entrega de versões em intervalos

planejados. Dessa forma, os processos do ciclo de vida são aplicados para a realização de cada versão do sistema, em paralelo à manutenção e suporte da versão anterior.

No modelo evolutivo, também há a entrega de versões em intervalos

planejados, com a diferença de que admite-se que os requisitos do produto possam evoluir ao longo do tempo.

207

Os modelos incremental e evolutivo são muito úteis para o desenvolvimento simultâneo, pois podem ser utilizados para antecipar os produtos de apoio em versões preliminares que satisfaçam os stakeholders possibilitando assim o desenvolvimento simultâneo dos elementos do sistema.

A escolha do modelo de desenvolvimento depende de muitos fatores: da maturidade da organização desenvolvedora, do conhecimento e maturidade dos requisitos, do prazo disponível, das tecnologias envolvidas e da dependência de fornecedores conforme observado no guia (ISO/IEC-TR-19760:2003) .

5.3.1.2 Processo de Engenharia de Sistemas Aplicado ao Produto

Espacial

A organização desenvolvedora do produto espacial deve aplicar as diretivas e

os processos de engenharia de sistemas das normas ECSS-E-ST-10C:2009, IEEE-STD-1220:2005 e ISO/IEC15288:2008.

Como organização iniciadora do processo de design do sistema, a organização desenvolvedora do produto espacial deve garantir que as interfaces organizacionais sejam estabelecidas e exercitadas durante a execução do projeto.

Para estabelecer e garantir o fluxo de dados das interfaces organizacionais, a organização responsável pelo produto espacial deve garantir a disponibilidade dos produtos de apoio do design do produto espacial para que as outras organizações possam acessar e simultaneamente desenvolver o processo de AIT e o GSE necessário. O mesmo princípio vale para as demais organizações desenvolvedoras que devem ser capazes de obter os produtos de apoio de design de entrada e fornecer os produtos de apoio de saída. As interfaces organizacionais são tratadas na Seção 5.3.4.

Embora o modelo de desenvolvimento do produto espacial e seus produtos decompostos seja o modelo “Vê”, isso não impede que o modelo de desenvolvimento sugerido por este guia para os produtos de poio de design do

208

produto espacial, isto é, simuladores, modelos, bancos de dados, entre outros, seja o modelo incremental ou evolutivo.

Os modelos incremental e evolutivo possuem a grande vantagem de disponibilizarem versões com características limitadas mas que capturam e documentam a definição da solução de engenharia do produto espacial nas fases iniciais do desenvolvimento, permitindo assim que o processo de AIT e o GSE sejam desenvolvidos em paralelo. O modelo evolutivo possui ainda a vantagem de iniciar o processo de desenvolvimento do processo de AIT com os requisitos não completamente definidos.

Dessa forma, especial atenção deve ser dada ao repositório de dados de produtos de apoio ao design. O repositório de dados deve ser capaz de permitir o desenvolvimento, armazenamento, e disponibilidade dos produtos de apoio aos stakeholders conforme clausula 5.6.3 da norma ECSS-E-ST-10C.

A organização desenvolvedora do produto espacial deve garantir que esse repositório seja disponibilizado em tempo correto para que as demais organizações desenvolvedoras possam (a) obter as baselines dos produtos de apoio de entrada necessárias para o processo de design de seus elementos e (b) prover as baselines dos produtos de apoio de saídas das soluções de seus elementos.

5.3.1.3 Processo de Engenharia de Sistemas Aplicado ao Processo de

AIT

De acordo com a norma IEEE-STD-1220:2005, assim que os processos do ciclo de vida são identificados nas fases iniciais do projeto, a organização desenvolvedora do sistema deve também aplicar o Processo de Engenharia de Sistemas – SEP para projetar, definir e realizar os processos do ciclo de vida.

Embora as normas IEEE-STD-1220:2005 e ISO/IEC15288:2008 tratem os processos do ciclo de vida como elementos do sistema (“building blocks”) a serem desenvolvidos, poucas diretivas específicas para a aplicação do SEP aos processos do ciclo de vida são apresentadas, e principalmente, quase

209

nenhuma diretiva sobre produtos de apoio gerados e necessários aos processos do ciclo de vida, i.e., documentos, modelos, simuladores, planilhas, desenhos, ou qualquer artigo de engenharia necessários e gerados durante o desenvolvimento dos processos dos ciclo de vida em especial nesta dissertação, o processo de AIT.

Essa vacância de diretivas e produtos de apoio gerados nos processos do ciclo de vida também é sentida nas normas ECSS-E-ST-10C (2009), ECSS-E-ST-10-02 (2009) e ECSS-E-ST-10-03 (2012) assim como no manual de engenharia de sistemas da NASA (2007).

De forma a adequar e correlacionar os produtos de apoio gerados no desenvolvimento do produto espacial no desenvolvimento do processo de AIT, e no desenvolvimento do GSE o presente guia propõe, de forma sistemática um fluxo de disponibilidade dos produtos de apoio necessários para o desenvolvimento do processo de AIT.

Para isso, é necessário identificar os produtos de apoio de design para planejamento, definição e desenvolvimento do processo de AIT conforme abordado na Seção 5.3.5. Dessa forma o presente guia estende a aplicação dos processos e diretivas das normas ECSS-E-ST-10C (2009), ECSS-E-ST-02C (2009) e ECSS-E-ST-03C (2012) com o objetivo de definir e estabelecer um conjunto de produtos de apoio de design ao processo de AIT.

Para o modelo de desenvolvimento dos produtos de apoio do processo de AIT

é sugerido o modelo incremental ou evolutivo. Esses modelos possuem a vantagem de disponibilizarem versões antecipadas que capturam e documentam a definição da solução de engenharia para o processo de AIT nas fases iniciais do desenvolvimento do projeto mesmo que com características limitadas.

A vantagem da disponibilização e antecipação da definição do processo de AIT é permitir que os elementos de GSE, que dependem dessas definições bem como de definições do produto espacial, possam ser definidos, mesmo que

210

com características limitadas, mas viabilizando assim a antecipação do design do GSE e com isso realimentando todo o projeto.

A troca de produtos de apoio de design entre os projetos do produto espacial, processo de AIT e GSE é apresentada com mais detalhe na Seção 5.3.6.

5.3.1.4 Processo de Engenharia de Sistemas Aplicado ao GSE

O GSE é o conjunto de produtos de apoio necessários para dar suporte às atividades de AIT. O GSE não é considerado um único sistema, mas sim um conjunto de elementos (alguns são sistemas e outros, não) que dão suporte às diferentes subsistemas e/ou fases do processo de AIT. O processo de engenharia de sistemas somente deve ser aplicado aos elementos do GSE que são sistemas.

O MGSE é o conjunto de elementos mecânicos formado por suportes, proteções, carrinhos de integração, ferramentas de montagem, contêineres de transporte, entre outros, que dão suporte as atividades do processo de AIT. Em geral, os elementos do MGSE são integrados ao produto espacial.

Por outro lado, o EGSE é um sistema formado por diversos elementos (sistemas ou não) que necessitam ser integrados entre si e igualmente validados antes de sua utilização com o produto espacial nas atividades de AIT.

Para a norma ISO/IEC15288:2008, durante um estágio do ciclo de vida, o produto de apoio relacionado deve ser considerado em conjunto com o sistema de interesse, ou seja, devido sua interdependência, sistema de interesse e produto de apoio devem ser considerados como um único sistema.

Os elementos do GSE surgem da decomposição do processo de AIT, mas também como reflexo da decomposição do sistema espacial.

Devido a essa natureza distribuída dos elementos do GSE, seu desenvolvimento normalmente é feito por várias organizações desenvolvedoras, o que contribui para soluções heterogêneas.

211

Da mesma forma como para qualquer produto, as organizações desenvolvedoras dos elementos do GSE devem aplicar o processo de engenharia de acordo com as normas IEEE-STD-1220:2005 e ISO/IEC15288:2008. A aplicação das normas ECSS devem ser ajustadas observando as particularidades de cada projeto.

Também deve ser observado a aplicabilidade de outras normas gerais e específicas de cada área tais como:

ISO:

ISO 14303 – Space System – Launch-vehicle-to-spacecraft interfaces;
ISO 14644-1 – Clean Rooms and Associated Controlled Environments – Classification of Air Cleanliness;
ISO 14625 (2007) – Space Systems – Ground Support Equipment for Use at Launch, Landing, or Retrieval Sites – General Requirements;
ISO/IEC TR 15271 (1998) – Guide for ISO/IEC 12207 (Software life cycle processes); · ISO 14620-1 (2002) – Space Systems – Safety requirements Part 1: System Safety

ECSS:

ECSS-E-70-41A (2003) – Ground Systems and Operations – Telemetry and Telecommand Packet Utilization;
ECSS-Q-ST-40C (2009) – Space Product Assurance – Safety40.

O elementos do GSE podem ter seu desenvolvimento antecipado, com a adoção do modelo incremental ou evolutivo de desenvolvimento, dado que seus requisitos podem não ser completamente conhecidos durante os processos de acordo (processos de aquisição e fornecimento), e seu design interno depender do design interno do produto espacial conforme observado por Halligan (2008).

40 A norma ECSS-Q-ST-40C aponta para a necessidade de que o GSE deva passar por análise de perigo e que deva possuir declaração de conformidade com a marca “CE” (sigla em francês de “Conformité Européene”) . Apesar da marca “CE” ser aplicável ao mercado europeu apenas, a auto-adequação com a marca “CE” é uma boa medida de qualidade e estratégica ao deixar o GSE apto a ser utilizado em campanhas de lançamento conduzidos por organização pertencente a comunidade européia.

212

Os elementos do GSE devem ser desenvolvidos em conjunto com desenvolvimento do processo de AIT que por sua vez se faz em conjunto com o desenvolvimento do produto espacial.

Em paralelo, o desenvolvimento dos elementos do GSE deve ser feito

simultaneamente aos elemento(s) do produto espacial ao(s) qual(quais) faz(em) interface com o GSE. Como exemplo, pode-se citar o desenvolvimento do AOCS SCOE (um dos elementos do EGSE) que pode ser desenvolvido em conjunto ao subsistema AOCS de um satélite.

Muitos dos elementos do GSE, EGSE e alguns MGSE podem ser utilizados em

mais do que um nível da hierarquia do sistema, permitindo assim a redução de custos ao não replicar um determinado elemento do GSE paras as atividades do nível acima na hierarquia do sistema. Para que isso ocorra de forma eficiente, é necessário que o SBS do sistema seja previamente e cuidadosamente preparado.

Devido a natureza acoplada dos elementos do GSE com o correspondente produto espacial, há um potencial risco de mudanças de requisitos especialmente do GSE que depende da solução de design o produto espacial.

De acordo com o DOD (2001), há quatro métodos para gestão de risco: evitar, controlar, transferir ou assumir o risco.

Controlar o risco é incorporar ao processo de design medidas para diminuir o risco a um nível aceitável. As técnicas de controle de riscos são abundantes e incluem (DOD,2001):

Design com múltiplas redundâncias;
Design alternativo com reconhecido baixo risco; · Desenvolvimento incremental planejado;
Design separado de componentes de alto risco; · Planejamento de teste, análise e correção;
Design robusto com margem substancial;
Abordagem de sistema aberto com ênfase no uso de interfaces padrões e reconhecidas.

213

Uma abordagem interessante no desenvolvimento do GSE devido ao potencial de risco de mudanças de requisitos é o uso do conceito de sistemas abertos (tradução livre de “Open Systems”).

5.3.2 Abordagem de Sistemas Abertos

Os Sistemas Abertos são caracterizados por serem sistemas de fácil modificação ou acréscimo de funcionalidade (DOD,2001). O conceito de Sistemas Abertos no desenvolvimento de GSE permite maior flexibilidade no atendimento aos requisitos, já que os elementos do GSE podem ser desenvolvidos com a previsão de evolução dos requisitos do GSE em função da evolução do design do produto espacial e do processo de AIT.

Essa abordagem é interessante pois enfatiza a utilização de interfaces comerciais, flexíveis e de comprovada aceitação com o objetivo de maximizar a flexibilidade na escolha de componentes similares ou alternativos com o objetivo de flexibilizar o desenvolvimento.

Do ponto de vista técnico, os sistemas abertos são aqueles que utilizam

interfaces de padrão aberto, design modular, design de interface que privilegie soluções múltiplas e utilização de componentes de prateleira.

Os benefícios da abordagem de sistemas abertos são a flexibilização do projeto, redução dos riscos de desenvolvimento, redução de custos, suporte a longo-prazo e o aumento do tempo de utilização com possível reutilização em outros projetos, reduzindo drasticamente o custo e necessidade de treinamento em sistemas novos.

5.3.3 Desenvolvimento Simultâneo

O objetivo desta seção é mostrar a interdependência do desenvolvimento do GSE ao desenvolvimento do processo de AIT e ao desenvolvimento do produto espacial como uma forma de justificar a necessidade e importância do desenvolvimento simultâneo.

214

Para Engenharia de Sistemas, os produtos de apoio aparecem na decomposição dos elementos do ciclo de vida do produto de interesse (IEEE-Std-1220:2005),(ISO/IEC15288:2008). Dessa forma o GSE como um produto de apoio ao processo de AIT, surge na decomposição hierárquica dos elementos do processo de AIT.

Os requisitos do GSE são originados do processo de AIT, conforme a premissa da hierarquia “top-down” do sistema presentes nas normas de engenharia de sistemas como IEEE-STD-1220:2005 e ISO/IEC15288:2008. Além dos requisitos advindos do processo de AIT (elemento hierarquicamente acima do GSE na hierarquia do sistema) e dos requisitos de interface com o produto espacial, a solução de design do produto espacial e seus produtos derivados também geram requisitos para o GSE, já que este deve ser capaz de dar suporte ao produto espacial (incluindo seus produtos derivados).

Uma amostra da dependência do GSE da solução de design do produto espacial pode ser extraído no Apêndice P da norma ECSS-E-ST-10C (ECSS,2009), que lista requisitos de conteúdo (DRD “Document Requirements Descriptions”) do Manual de Usuário do produto. Esta DRD requisita que o manual de usuário descreva instruções e GSE necessário para manuseio, armazenamento e instalação. Porém a DRD para Manual de Usuário de Produto presente na norma ECSS-E-ST-10C não aponta a necessidade de GSE para operação e teste durante as atividades de AIT. Aponta apenas de forma genérica para a fase de instalação.

Para os elementos do EGSE, esse acoplamento do design do produto espacial (incluindo seus produtos decompostos) com o produto de apoio ao processo de AIT é ainda mais presente já que a função do EGSE é de operar e testar as funções intrínsecas do produto espacial presentes em sua solução de design.

De acordo com a norma ECSS-E-ST-10C a primeira baseline da especificação de requisitos do GSE deve ser apresentada somente na Revisão Preliminar de Projeto – PDR do produto espacial ao final da fase B do projeto. E a última

215

versão revisada da especificação do GSE deve ser apresentada na Revisão de Aceitação – AR do produto espacial ao longo da fase D do projeto.

Sem o desenvolvimento simultâneo, o desenvolvimento do GSE somente deveria ser iniciado após a completa definição do produto espacial conforme trecho da norma EIA-632 (ANSI,2003) reproduzido abaixo:

“O desenvolvimento de um produto de apoio é normalmente iniciado após o

produto de interesse relacionado estar completamente definido e após os

requisitos do produto de apoio estarem identificados” EIA-632 (ANSI,2003

p.48).

Aguardar a completa definição dos requisitos do produto de apoio (GSE) para iniciar seu desenvolvimento, pode atrasar o produto espacial, já que este depende dos produtos de apoio (GSE) para sua montagem e verificação, e pode também gerar modificações no próprio produto espacial, já que requisitos e restrições podem surgir em função da solução de design do GSE, ocasionando mais atrasos ao projeto.

Por sua vez, o processo de AIT de um produto espacial depende do Plano de

Verificações, derivado dos requisitos, e do Plano Tecnológico. O Plano Tecnológico, por sua vez, é construído baseado na maturidade do desenvolvimento tecnológico ou TRL (tradução do inglês “Technology Readiness Level”) do produto espacial (e seus produtos decompostos), ou seja o processo de AIT, e, por consequência, a matriz de testes depende do TRL do produto espacial e seus produtos. Porém essa dependência do Plano de Verificação e do processo de AIT ao TRL do produto espacial não aparece nas normas ECSS-E-ST-10-02 e ECSS-E-ST-10-03.

O processo de AIT não apenas impõe requisitos ao GSE mas também depende de suas características, suas funcionalidades como automatismo, acessibilidade, segurança etc. Ou seja, o processo de AIT é intrinsicamente acoplado às funcionalidades de suas ferramentas. É uma relação biunívoca e não apenas “top-down” presente na premissa do processo de engenharia de

216

sistemas na decomposição de um sistema em elementos especificados de cima-para-baixo na hierarquia do sistema.

O sistema espacial, por sua vez é desenvolvido com o objetivo de atender a requisitos operacionais, embora restrições devam ser identificadas nos processos não operacionais de fabricação, montagem, testes etc (IEEE-Std-1220:2005).

Essa interdependência entres esses três elementos do sistema faz com que produto de interesse, seu processo do ciclo de vida e os produtos de apoio devam ser analisados em conjunto simultaneamente e interativamente, pois a solução de um afeta nos requisitos dos demais, em um círculo de interdependência.

Engenharia Simultânea é mais uma abordagem e cultura organizacional do que uma metodologia. Não há uma receita igual para todos os casos, mas sim uma série de princípios que devem ser incorporados à organização (DOD,1998) Stjepandićet al (2015):

Foco nos stakeholders;
Desenvolvimento simultâneo de produtos e processos;

a. Planejamento antecipado e contínuo do ciclo de vida do produto; b. Identificação e gerenciamento de risco;

Maior flexibilidade em contratos com fornecedores; · Compartilhamento de Informação;

a. Controle e Configuração; b. Registro e Documentação.

O Desenvolvimento simultâneo de produtos e processos somente é possível com suporte computacional adequado. O processo de desenvolvimento deve ser feito em ambiente computacional que permita a criação de modelos e simuladores.

O uso de simuladores e modelos permite a troca eficiente de informação entre as equipes desenvolvedoras. Segundo Stjepandić et al (2015), para isso é importante não apenas as ferramentas de modelagem e simulação, mas um sistema de gerenciamento de informação que permita o intercambio de

217

informação de forma segura, eficiente, conforme abordado nas Seções 2.9.2.2 e 2.9.2.4.

5.3.4 Interfaces Organizacionais

Para dar suporte ao desenvolvimento simultâneo dos elementos correlatos do sistema: o produto espacial, seu processo de AIT e o GSE necessário, é preciso que se estabeleça uma rede de equipes de desenvolvedores integrados e que representem todos os stakeholders. Essa rede de organizações desenvolvedoras deve ser cuidadosamente estabelecida e organizada pelo SBS a fim de maximizar a comunicação vertical (hierarquia do produto) e horizontal (entre elementos do SBS) durante o processo de desenvolvimento (DOD,2001).

Omissões ou incompatibilidades na definição do SBS mascaram potenciais problemas e podem levar a atrasos no projeto .

Como cada elemento correlato do sistema deve ser desenvolvido simultaneamente pela sua respectiva organização desenvolvedora, a interface entre as organizações desenvolvedoras passa a ser de extrema importância para o sucesso do projeto do sistema.

É preciso estabelecer o momento e quais informações de cada projeto são necessárias para que as organizações desenvolvedoras possam trabalhar simultaneamente no desenvolvimento de seus projetos.

O desafio em estabelecer o fluxo de informações entre os projetos durante o seu desenvolvimento é determinar não apenas o conteúdo da informação mas também em que fase essa informação (baseline) é necessária e suficiente aos demais projetos.

O conteúdo da informação técnica necessária para cada projeto é muito específico do próprio produto de apoio e seus elementos correlatos: fase do processo de AIT e o produto espacial. Portanto, não é objetivo deste guia entrar em detalhes técnicos em relação ao conteúdo, mas sim sistematizar esta relação e mostrar quais categorias e tipos de informação devem ser trocadas

218

entre as organizações desenvolvedoras para que as estas possam aplicar nos seus processos de desenvolvimento e estabelecer previamente o conteúdo técnico necessário para cada fase dos respectivos projetos.

Esse conjunto de informações de design i.e., modelos, simuladores, diagramas,

tabelas, documentos, entre outros, chamaremos no contexto dessa dissertação de produtos de apoio ao design.

Este guia, ao correlacionar os desenvolvimentos da tríade de elementos correlatos do sistema, tem o objetivo prático de identificar os produtos de apoio de design, seu conteúdo evolutivo e suficiente de forma a sistematizar o fluxo de informação entre as organizações desenvolvedoras.

O desenvolvimento simultâneo do produto espacial, seu processo de AIT e o GSE necessário pode ser visto como um Envolvimento Antecipado de Fornecedores – ESI (sigla em inglês para Early Supplier Involvement).

5.3.4.1 Interface Cliente-Fornecedor

Na engenharia de sistemas, a cada decomposição de um produto em

elementos do nível abaixo na hierarquia do produto, origina-se um relacionamento entre as organizações desenvolvedoras do produto e dos elementos decompostos deste produto. Esse relacionamento entre organizações pode se dar externamente entre diferentes empresas ou internamente entre departamentos ou pessoas de uma mesma empresa. Contudo, em ambos os casos uma interface organizacional está formada e necessita ser definida para o bom andamento de todo o projeto.

Normalmente a definição da interface inter-organizacional, está presente no

acordo entre as partes, contrato ou SOW (sigla em inglês de Statement Of Work), sendo mais formal quando envolve diferentes empresas.

O Processo de Acordo, da norma ISO/IEC15288:2008, que engloba o Processo de Aquisição e o Processo de Fornecimento possui os elementos essenciais para um acordo cliente-fornecedor quando se conhece a totalidade dos

219

requisitos no momento da contratação mas é insuficiente para o desenvolvimento simultâneo.

5.3.4.2 Envolvimento Antecipado de Fornecedores

O Envolvimento Antecipado de Fornecedores – ESI (tradução de “Early Suppliers Involvement”), nas fases iniciais do projeto pode trazer muitos benefícios em termos técnicos e de custos além de agilidade ao projeto como um todo, mas também pode trazer inúmeras dificuldades gerenciais conforme enumerado por (FREIN,2006):

Principais problemas relacionados ao ESI:

falta de transparência e confiança; · diferenças culturais;
atrasos causados por tempo subestimado;
dificuldades de implementar mudanças no processo de acordo; · dificuldade de engajamento durante o projeto;
dificuldade de estabelecer critérios de aceitação; · propriedade intelectual;
problema no processo de especificação: definição e evolução.

Conforme argumentam Le Dan et al (2008), o maior obstáculo ao envolvimento antecipado de fornecedores é a falta de experiência gerencial necessária para a complexa configuração inter-organizacional, necessitando assim do desenvolvimento de competências específicas não apenas ao fornecedor como também ao cliente, já que o sucesso dessa relação depende de ambos.

Ainda segundo Le Dan et al (2008), muitos autores concordam que a avaliação apenas do fornecedor não é suficiente para garantir melhoria do desempenho do relacionamento.

Segundo Araujo et al (1999) o relacionamento inter-organizacional necessita

construir uma interface interativa onde as decisões são tomadas com a participação de ambos os lados da díade.

220

Le Dain et all (2008) identifica 5 processos chave distribuídos em 3 fases para possibilitar o envolvimento antecipado de fornecedor:

Fase de Preparação:

o Processo de decisão de desenvolver ou comprar -· Fase de Formação:

o Processo de seleção de fornecedor; · Fase de Gerenciamento e Conclusão:

o Processo de gerenciamento colaborativo;

o Processo colaborativo e seguro de trabalho; o Processo de avaliação de desempenho.

5.3.4.2.1 Fase de Preparação

A fase de preparação é iniciada com a avaliação da necessidade de compra ou desenvolvimento de determinado elemento. Essa decisão deve de ser tomada de forma transversal e sistemática e que analise (baseado em Le Dain (2008)):

A competência interna;
A disponibilidade interna de recursos;
O grau de confiança do cliente no fornecedor para expor informação do projeto;
Os riscos associados ao relacionamento colaborativo;
A arquitetura do produto com relação as interfaces bem definidas; · A analise do fornecedor.

5.3.4.2.2 Fase de Formação

O processo de seleção de fornecedor, executado na fase de formação,

necessita de um alto grau de profissionalismo para garantir que a futura parceria desenvolva a sinergia esperada. Esse processo deve envolver diferentes membros do projeto com projetistas, pessoal de compras, qualidade, produção entre outros, que devem definir o escopo, o objetivo, o cronograma, a divisão de responsabilidades e os critérios de aceitabilidade da relação. Por outro lado, o fornecedor deve ser escolhido baseado em critérios de habilidades técnicas, habilidades organizacionais e orientação estratégica.

Uma vez escolhido o fornecedor, é necessário estabelecer as regras do

relacionamento para que a relação seja de ganho para ambos os lados, incluindo:

221

Objetivos e premissas;
Papeis desempenhados e responsabilidades;
Medidas de desempenho (cliente e fornecedor); · Listas de entregáveis para cliente e fornecedor;
Acordo de confidencialidade, e politica de propriedade intelectual; · Identificação dos métodos e processos compartilhados;
Gerenciamento de decisões e configuração.

5.3.4.2.3 Fase de Gerenciamento e Conclusão

O processo de gerenciamento colaborativo deve estabelecer um ambiente de confiança e aprendizado mútuo com o objetivo de aumentar as capacidades colaborativas. Este ambiente é baseado em três vetores importantes (baseado em Le Dain (2008)):

Atmosfera:

o Respeito mútuo e confiança;

o Respostas imediatas a quaisquer questões e demandas,

o Habilidade de capturar ou justificar a não aceitação das sugestões do fornecedor,

o Facilidade de criar um relacionamento inter-organizacional em todos os níveis.

Avaliação:

o Avaliação conjunta do cliente e do fornecedor, · Conhecimento:

o Capitalização de conhecimento e lições aprendidas para uso em projetos futuros.

5.3.5 Produtos de Apoio de Engenharia de sistemas

Durante o desenvolvimento de um produto, uma série de produtos de apoio de engenharia tais como: modelos, simuladores, documentos em texto, documento em forma de diagramas, planilhas ou quaisquer artigos de engenharia, são produzidos para especificar, planejar, definir e justificar o design do produto de interesse. Para produtos espaciais, a norma ECSS-E-ST-10C sugere uma lista de documentos a serem apresentados nas revisões de projeto, conforme reproduzida na Tabela 2.2.

222

Para possibilitar o desenvolvimento simultâneo da tríade de elementos (o produto espacial, o processo de AIT e o GSE) este guia propõe expandir a lista apresentada da Tabela 2.2 da norma ECSS-E-ST-10C incluindo também produtos de apoio presentes na norma IEEE-STD-1220:2005, incluindo quaisquer artigos produzido como modelos, simuladores, desenhos e planilhas entre outros, são classificados em cinco categorias (ECSS‐M‐ST‐10C:2009):

Documentos de missão;
Documentos de especificação; · Documentos de planejamento; · Dossiê de definição;
Dossiê de justificação.

A lista apresentada na ECSS-E-ST-10C:2009 embora genérica é mais apropriada para desenvolvimento de produtos (produtos de interesse ou de apoio) e portanto necessita ser adaptada para ser aplicada ao desenvolvimento de processos. Nas subseções seguintes cada categoria de documento é apresentada tanto para o desenvolvimento de produto, conforme presente na norma ECSS-E-ST-10C:2009, como para desenvolvimento do processo de AIT.

Cabe lembrar, que quando se aplica a recursividade do Processo de Engenharia de Sistemas – SEP da norma para desenvolver um produto de apoio, este passa a ser visto neste contexto como um produto de interesse (ECSS-E-ST-10C:2009). Portanto não há distinção de produto de interesse e produto de apoio em termos de documentação de saída do processo de engenharia de sistemas.

5.3.5.1 Documentos de Missão

O principal documento desta categoria é o Documento de Descrição de Missão – MDD (“Mission Description Document”) .

223

5.3.5.1.1 Documentos de Missão para Produto

O objetivo do Documento de Descrição de Missão é prover entrada para a

posterior seleção de conceitos que satisfaçam a missão durante as interações da especificação preliminar de requisitos técnicos.

O Documento Descrição de Missão – MDD é preparado nas Fases 0 e A pelo organização responsável pela missão e define o conceito para atender aos requisitos preliminares de projeto. O MDD é feito para cada conceito.

Principal Conteúdo para Produto (ECSS-E-ST-10C:2009):

Requisitos técnicos preliminares;

Descrição do conceito – análise da missão, descrição dos elementos;

Descrição de cada fase da missão

Avaliação do desempenho

Identificação de áreas de riscos”

5.3.5.1.2 Documentos de Missão de AIT

O objetivo do documento de missão de AIT é prover entrada para a organização desenvolvedora que realizará o AIT. Esse documento tem como objetivo servir de base para estabelecer a interface inicial entre a organização responsável pelo produto espacial e a organização responsável pelo AIT.

O Documento Descrição de Missão (MDD) do AIT deve descrever em linhas gerais o processo de AIT demandado, os objetivos e os principais eventos. Para cada conceito de AIT identificado no trade-off deve-se identificar os processos, esforços e GSE necessário. Esse documento deve ser construído em conjunto com a Dossiê de Definição de Design – DDF, o Dossiê de Justificativa de Design – DJF e Plano de Verificação do produto espacial.

O MDD do AIT é em linhas gerais uma descrição preliminar de alto nível dos possíveis conceitos de AIT e serve de entrada para a preparação dos requisitos técnicos e paralelamente da definição do conceito de AIT selecionado.

Principal Conteúdo para AIT:

224

Descrição geral do conceitos de AIT;

Identificação das fases de AIT;

Identificação do GSE e Infraestrutura;

Identificação dos Recursos necessários;

Identificação preliminar das atividades críticas e possíveis impactos;

Conclusão e comparações entre os possíveis conceitos de AIT.

5.3.5.2 Documentos de Especificação

O documento de especificação de requisitos técnicos (TS) tem por objetivo estabelecer os requisitos operacionais e de performance e associadas restrições em determinados ambientes.

O documento de especificação técnica (TS) exprime os requisitos técnicos congelados a serem satisfeitos por uma solução proposta de projeto.

É importante observar que o documento de especificação técnica deve ser escrito no domínio do problema e portanto não deve direcionar a uma solução de design.

5.3.5.2.1 Documentos de Especificação de Produto

O documento de especificação técnica – TS deve descrever o produto e seu contexto, incluindo seu ciclo de vida tais como: eventos de AIT, transporte, condições de testes, interface e instalação com o lançador, fase de lançamento, funcionamento em órbita e seu fim de vida.

Principal Conteúdo para Produto (ECSS-E-ST-10C:2009):

1. Apresentação das necessidades dos usuários;

2. Conceito e apresentação do produto;

3. Descrição do Ciclo de vida;

4. Restrições impostas pelo ambiente;

5. Requisitos: Identificação, performance, rastreabilidade, tolerância, verificação.”

225

5.3.5.2.2 Documento de Especificação de AIT

O objetivo do documento de especificação de AIT é identificar e estabelecer os

requisitos técnicos e gerenciais para a execução das atividades de AIT. O documento de especificação de AIT deve estar alinhado com:

a) os conceitos de AIT identificados;

b) os processos organizacionais de qualidade;

c) as normas aplicáve

O documento de requisito de AIT relacionado ao produto espacial é feito em conjunto pela organização desenvolvedora do produto espacial e a organização responsável pelo processo de AIT, e serve de entrada para seleção final do conceito de AIT adotado e para o desenvolvimento de uma solução de AIT.

O documento de requisitos de AIT deve ser elaborado baseado nos requisitos do produto espacial, no Plano de Verificação do produto espacial e nas normas aplicáveis ao processo de realização, montagem e teste. O documento deve incluir requisitos de interface entre os elementos do GSE e o produto espacial.

O documento de requisitos de AIT deve cobrir requisitos técnicos, gerenciais, logísticos e de qualidade para as atividades de AIT e servirão de base, para o processo de acordo entre a organização desenvolvedora do produto espacial e da organização desenvolvedora do processo de AIT.

Principal Conteúdo para AIT:

Modelos e Objetivos;

Organização e Responsabilidades;

Requisitos de Cronograma;

Requisitos Gerais;

Requisitos Especiais;

Requisitos de Documentação (entrada e saída);

Requisitos de GSE;

Requisitos de Qualidade;

226

Requisitos de Segurança.

5.3.5.3 Documentos de Planejamento

A norma ECSS-E-ST-10C lista os seguintes documentos de planejamento:

Plano Tecnológico; · Matriz Tecnológica;
Plano de Verificação; · Plano de AIT;
Plano de Mitigação de Detritos 41; · Plano de Evolução do Produto;
Plano de Revisões e Fases; · Descrição dos Processos;
Doc. Sistema de Coordenadas.

5.3.5.3.1 Documentos de Planejamento de Produto

O objetivo dos Planos de Engenharia de Sistemas – SEP é definir a abordagem, métodos, procedimentos, recursos, e a organização para coordenar e gerenciar todas atividades técnicas para especificar, projetar, verificar, operar e manter o sistema ou produto em acordo com os requisito do cliente. O SEP cobre todo o ciclo de vida do produto e deve evidenciar os riscos, elementos críticos, tecnologias específicas bem como as comonalidades, e possível reuso e padronizações.

Principal Conteúdo para Produto (ECSS-E-ST-10C:2009):

Objetivos e Restrições;

Evolução do Produto;

Fases do projeto e o plano de revisões;

Estratégia de Aquisição;

Itens críticos ;

41 Aplicável somente para produtos espaciais.

227

Entradas de engenharia de sistemas;

Saídas de engenharia de sistemas;

Responsabilidades e Organização;

Interfaces de Engenharia de sistemas

10. Descrição das atividades de SE;

11. Integração das disciplinas de engenharia.

O Plano Tecnológico – TP é uma das entradas importantes para o Plano de

Verificação – VP. O TP também é uma importante entrada para identificação de itens críticos em AIT.

O Plano de Verificação contém a estratégia geral da verificação, incluindo a filosofia dos modelos.

O Plano de Verificação juntamente como o Documento de Controle de Verificação são as principais entradas para o Plano de AIT.

5.3.5.3.2 Documentos de Planejamento de AIT

O objetivo dos documentos de planejamento de AIT é definir métodos, processos, recursos e as responsabilidades para implementar e realizar a solução de AIT ao produto espacial.

Os documentos de planejamento de AIT devem considerar todos os modelos e suas particularidades em acordo com o Plano de Desenvolvimento. Os seguintes modelos podem fazer parte do plano de desenvolvimento: Modelo Engenharia – EM, Modelo de Qualificação – QM, Modelo de Qualificação e Voo – PFM, Modelo de Voo – FM.

Para cada modelo, normalmente um documento intitulado Plano de AIT é produzido. Para os modelos PFM e FM, a campanha de lançamento deve ser incluída no documento.

228

O plano de AIT deve ser feito a partir do conceito de AIT selecionado e deve estar em sintonia com os planos de desenvolvimento e de verificação do produto espacial.

O plano de AIT sintetiza em linguagem gerencial, as decisões técnicas

definidas e desenvolvidas no Dossiê de Definição de Design – DDF do AIT e estabelece a sequência das atividades que atenda ao cronograma mestre do sistema (ou produto).

O plano de AIT deve considerar as atividades críticas em AIT (processo, materiais, recursos) identificadas no Plano Tecnológico aos quais a organização responsável pelo AIT não possua maturidade ou que possam pôr em risco o produto, o custo ou o cronograma.

O plano de AIT é preparado pela a organização responsável pelo AIT a partir do documento de requisitos de AIT do produto espacial, do plano de desenvolvimento, do plano de verificação e plano de mitigação de detritos.

Principal Conteúdo para Produto (baseado em ECSS-E-ST-10-03C:2012):

Apresentação do Produto – Modelos e estado;

Programa de Montagem Integração e Testes:

a. Planejamento das atividades;
b. Matriz de testes (requisitos de testes rastreado para procedimentos);
Tempo esperado da atividade;
d. Restrições operacionais e de segurança. GSE e Infraestrutura;

Documentação de AIT ;

Organização e Gerenciamento:

a. Responsabilidades e Organização, b. Ferramentas de gerenciamento,
Relação de Garantia do Produto, Qualidade e Configuração, d. Revisões planejadas,
e. Política de reuniões de coordenação.

229

5.3.5.4 Dossiê de Definição de Projeto

A norma ECSS-E-ST-10C lista os seguintes tipos de documentos dentro da categoria de definição de projeto:

Árvore de Funções; · Árvore de Produto;
Árvore de Especificação; · Budget Técnico;
Especificações Técnicas de Requisitos Preliminares para o nível abaixo;
Especificações Técnica de Requisitos para o nível abaixo;
Arquivo de Definição de Design para o próximo nível abaixo; · Doc. Controle de Interface;
Manual de Usuário do Produto.

O objetivo do Dossiê de Definição de Projeto – DDF é definir tecnicamente a solução que atenda aos requisitos técnicos especificados.

Os produtos de apoio dentro desta categoria, dependem da natureza do projeto, hardware, software ou processo, bem como de seu tamanho.

5.3.5.4.1 Dossiê de Definição de Produto

O Dossiê de Definição de Projeto (DDF) é a estrutura básica com todas as

características e informações da arquitetura física e funcional do produto, necessárias para fabricação, montagem, operação, suporte e gerenciamento de configuração. O DDF é a coleção de todos os artigos de engenharia (produtos de apoio ao design) que descreve e estabelece o produto tais como: especificação do nível abaixo, descrição do design e das interfaces, desenhos, esquemas, modelos, restrições específicas oriundas das soluções adotadas (materiais, processos entre outros).

O DDF detalha a configuração “as-design” e é a referência para os processos

de produção, de AIT, de operação e de manutenção do sistema.

Principal Conteúdo para Produto (ECSS-E-ST-10C:2009):

230

Descrição sumária dos requisitos do produto;

Descrição das funções: arquitetura e árvore de funções;

Descrição física: arquitetura, árvore de produtos e de especificação;

Descrição das interfaces;

Budget, margens e desvios;

Restrições do ciclo de vida;

Referência ao banco de dados de engenharia;

Manual de usuário.

Como requisito geral para desenvolvimento de sistemas, a norma IEEE-STD-1220:2005 aponta para a necessidade de desenvolvimento do pacote de dados integrado para hardware, conforme reproduzido na Tabela 5.1, e para software, reproduzido na Tabela 5.2.

231

Tabela 5.1 – Produtos de Apoio de Design de Hardware

Fonte: (IEEE-Std-1220:2005)

232

Tabela 5.2 – Produtos de Apoio de Design de Software

Fonte: (IEEE-Std-1220:2005)

5.3.5.4.2 Dossiê de Definição de AIT

O Dossiê de Definição de AIT é a estrutura básica da solução de design para o processo de AIT, com todas as características e informações técnicas necessárias para as atividades de AIT.

O DDF é a coleção de toda a artigos de engenharia (produtos de apoio ao design) que estabelece e detalha as atividades de AIT tais como: descrição da sequência das atividades, das fases, das atividades de cada fase, matriz de testes, configuração detalhada do produto em cada uma das atividades, descrição do design e das interfaces, desenhos, esquemas, modelos, restrições específicas oriundas das ferramentas, recursos e processos.

Os objetivos do Dossiê de Definição de AIT são:

1. Definir tecnicamente as configurações do produto e das ferramentas necessárias para o processo de AIT (GSE e infraestrutura).
2. Definir tecnicamente as funcionalidades e as interfaces das ferramentas necessárias ao processo de AIT,

3. Definir e desenvolver tecnicamente os processos e seus procedimentos para as atividades de AIT,

4. Definir os recursos humanos e o treinamento necessário para desenvolver e realizar os processo de

O Dossiê de Definição de AIT é produzido em conjunto com do Plano de AIT, e

com o Dossiê de Definição de Projeto do produto espacial e a partir da das características da infraestrutura e recursos disponíveis e especificados.

233

Como requisito geral para desenvolvimento de sistemas, a norma IEEE-STD-1220:2005 aponta para a necessidade de desenvolvimento do pacote de dados integrado para serviços e processos conforme reproduzido na Tabela 5.3.

Tabela 5.3 – Produtos de Apoio de Design de Processo

Produto de Apoio de Design para Processo	Descrição
Manpower, pessoal e documentação de treinamento	Documentam os conhecimentos, habilidades, requisitos de treinamento e necessidade de pessoal para operar, manter e assistir o produto ao longo dos estágios do ciclo de vida.
Desenho de arranjo do espaço de trabalho	Documentam a disposição de equipamentos e pessoal em um determinado estágio do ciclo de vida com os principais subsistemas ou componentes do produto.
Especificação de interface Homem-Máquina	Documento em forma de diagramas para documentar todas as interfaces entre os seres humanos que suportam o ciclo de vida do produto e qualquer aspecto do produto incluindo interfaces humanas, interfaces homem-hardware e interfaces homem-software.
Diagramas de sequência operacional	Documentos em forma de representação gráfica que documentam a interação entre seres humanos e outros subsistemas ou componentes do sistema no desempenho de uma tarefa ao longo do tempo.
Diagrama de captura ontológica de Componente	Documento em forma de representação gráfica que documentam a como um produto é formado por componentes ou como um produto muda de estado de acordo com IDEF5 (PERAKETH,1994)
Procedimento	Documenta as ações que o pessoal de suporte realiza para desenvolver, produzir, testar, distribuir, operar, apoiar e dispor do sistema ou seus produtos, ou treinar os seres humanos para realizar essas ações. Esses procedimentos podem ser na forma de diagramas de seqüência operacional, listas ou tabelas.
Especificação de segurança	Documenta as características de projeto do equipamento / produto especificações de desempenho e treinamento que reduzem o potencial de erros ou falhas humanas ou de máquina que possam causar ferimentos ou morte dentro dos limites operacionais, tempo e custo ao longo do ciclo de vida do equipamento / produto.

234

Fonte: baseado em IEEE-STD-1220:2005

Figura 5.4 – Exemplo de Diagrama IDEF5 do Módulo de Carga Útil de um Satélite

235

5.3.5.5 Dossiê de Justificativa de Projeto

O objetivo do dossiê de justificativa de projeto é apresentar e demonstrar as razões pela escolha da solução de projeto. O DJF é progressivamente preparado durante o detalhamento do produto ou processo. O DJF deve apresentar os “trade-offs” e análises que dão suporte as decisões de projeto definidas na DDF.

5.3.5.5.1 Dossiê de Justificação de Produto

O DJF em conjunto com o Dossiê de Definição de Design e os Requisitos

Técnicos formam a base para desenvolvimento do produto.

Principal Conteúdo para Produto (ECSS-E-ST-10C:2009):

1. Descrição de projeto;

2. Justificativa do design: destaque dos requisitos não atendidos, críticos e análises de risco.

3. Justificativa da Arquitetura funcional;

4. Justificativa da arquitetura física;

5. Síntese das atividades de desenvolvimento;

6. Síntese das atividades de verificação (plano de verificação, modelos, evidência de qualificação…);

7. Justificativa dos budgets;

8. Justificativa das restriçõe

De acordo com a norma ECSS-E-ST-10-02C fazem parte desta categoria os seguintes documentos para produto:

Documento de Controle de Verificação – VCD; · Especificação de Teste – TSPE;
Relatório de Análise – ARPT;
Relatório de Revisão de Projeto – RRPT; · Relatório de Verificação – VRPT.

236

O Documento de Controle de Verificação – VCD lista todos os requisitos para serem verificados juntamente com o método selecionado e no estágio e nível aplicável.

5.3.5.5.2 Dossiê de Justificação de AIT

Os objetivos do dossiê de justificativa do AIT são:

1. Apresentar e demonstrar as razões pela escolha da solução de AIT;
2. Apresentar e demonstrar que as atividades foram executadas conforme planejamento.

O DJF de AIT é progressivamente preparado durante o detalhamento do

conceito de AIT. O DJF de AIT deve apresentar os “trade-offs” e análises que dão suporte as decisões de projeto definidas na DDF de AIT. O DJF em conjunto como DDF e TS de AIT descrevem completamente o processo de AIT.

Principal Conteúdo para AIT :

1. Descrição do conceito de AIT,

2. Justificativa do conceito de AIT: destaque dos requisitos não atendidos, atividades críticas e análises de risco.

3. Justificativa da sequência de atividades: Avaliação e comparação “trade-offs” da sequência de atividades;

4. Justificativa da arquitetura física: áreas de conhecimento, treinamento, GSE, infraestrutura e processo

5. Síntese das atividades de desenvolvimento de AIT: treinamentos, GSE, infraestrutura e procedimento.
6. Síntese das revisões TRR e TRB,

7. Justificativa dos budgets;

8. Justificativa das restrições.

De acordo com a norma ECSS-E-ST-10-02C fazem parte desta categoria os seguintes documentos para processo de AIT:

237

Procedimento de Teste – TPRT; · Relatório de Teste – TRPT;
Relatório de Inspeção – IRPT.

5.3.6 Correlação entre os Produtos de Apoio

A Figura 5.5 mostra de forma global as interfaces técnicas em termos de produtos de apoio entre as organizações desenvolvedoras do produto espacial, do AIT e do GSE necessário.

Figura 5.5 – Interfaces Organizacionais para desenvolvimento de produto espacial, AIT e GSE

238

A descrição de cada uma das interfaces identificadas na Figura 5.5 é apresentada nos próximos parágrafos:

5.3.6.1 Planejamento de AIT: Interface (1)

A preparação dos planos de engenharia do produto espacial, a saber: plano programático, o plano tecnológico, plano de verificação, plano de mitigação de riscos, plano de operações, entre outros, deve começar o quanto antes na Fase 0. Nessa categoria, inclui-se também o plano de AIT que é preparado pela organização responsável pelo AIT. Os planos de engenharia e o plano de AIT são bastante dependentes um do outro sendo que os planos de engenharia são as entradas para a preparação do plano de AIT, mas esse também realimenta os planos de desenvolvimento (1). Esses planos devem ser preparados em conjunto e dependem de muitos fatores como quantidade de modelos, maturidade do projeto, entre outros, informações que evoluem rapidamente durante as Fases 0 e A de desenvolvimento.

O plano de AIT necessita de entradas do plano de verificação e dos planos de

engenharia (1) quanto aos requisitos que serão verificados por testes ou inspeção, o número e tipo dos modelos, a maturidade do design, o cronograma de disponibilidade das unidades e subsistemas e a janela alocada no cronograma máster.

Por outro lado os planos de engenharia necessitam de informações quanto as restrições impostas no AIT, como capacidades limites, necessidade de GSE específico, interfaces adicionais no produto espacial, criticidades das atividades e portanto necessidade de ajustes no projeto do produto espacial para mitigar riscos durante AIT, e uma realimentação do cronograma de AIT em comparação à janela alocada no cronograma mestre.

5.3.6.2 Especificação de AIT: Interfaces (2), (3) e (4):

Os planos de engenharia de sistemas impõem muitos requisitos ao processo de AIT (2) quanto a qualidade, verificação, tecnologias utilizadas, mitigação de riscos e mitigação de detritos. Os requisitos de AIT são levantados a partir dos

239

requisitos gerais de qualidade, dentro do plano de qualidade e em acordo com os processos internos à organização desenvolvedora. Também fazem parte desta interface os requisitos específicos do produto espacial dentro dos planos de engenharia, tais como pontos de inspeção, testes funcionais e ambientais dentro do plano de verificações e logística do plano de desenvolvimento.

Os requisitos de AIT são elaborados baseados nos requisitos do produto espacial, na verificação de funções e interfaces (3), mas também deve atender às necessidades específicas da solução do produto espacial e seus produtos derivados (4) tais como modelos e simuladores, tecnologias específicas que demandam procedimentos específicos.

5.3.6.3 Definição de Design de AIT: Interface (5):

A definição das atividades de AIT (DDF AIT) são derivadas diretamente dos requisitos de AIT, em um processo interno à organização de AIT, mas também da evolução das definições do design do produto espacial no que concerne tecnologias, materiais e acessibilidade, matrizes de verificação e consequentemente do plano de verificação (5), ou seja a solução de design do produto espacial impõe ao processo de AIT necessidades tais como sequência de montagem, pontos de inspeção, MGSE específicos de suporte, proteção ou manuseio durante atividades de AIT, entre outras. Isso ocorre, pois muitas dessas necessidades não são formalmente explicitadas como requisitos de AIT, pois são consequências das soluções desenvolvidas no produto espacial e seus elementos decomposto.

5.3.6.4 Realimentação no Design do Produto Espacial: Interface (6):

Conforme a definição do AIT evolui no seu detalhamento, é possível que sejam identificados atividades, operações ou testes em AIT que necessitam de interfaces ou funcionalidades específicas do produto espacial (6).

Também fazem parte desta interface, necessidades operacionais durante a campanha de lançamento.

240

5.3.6.5 Especificação do GSE: Interfaces (7), (8), (9) e (10):

O detalhamento da definição do processo de AIT é uma parte importante das entradas para definição dos requisitos dos elementos do GSE (7). Normalmente os requisitos técnicos do GSE são definidos em conjunto pela organização responsável pelo AIT, e pela organização responsável pelo produto espacial.

A organização desenvolvedora do AIT faz a primeira decomposição do GSE em elementos do GSE específicos para cada subsistema do produto espacial, para integração dos subsistemas e para as fases do AIT.

Os elementos do GSE, recebem então requisitos de automatismo,

acessibilidade, qualidade, rastreabilidade e segurança advindos da organização desenvolvedora do AIT (8).

Devido as especificidades de cada elemento GSE, estes recebem requisitos específicos do detalhamento da definição do produto espacial. Este detalhamento está ligado aos requisitos de nível abaixo na estrutura hierárquica do produto espacial (9). A disponibilização de modelos e simuladores em ambiente de AIT é essencial para que sejam levantados requisito ao GSE. Requisitos nesta categoria estão relacionados a requisitos de interfaces, de funcionalidade e de desempenho e sua correspondente verificação após integração (10).

Dependendo do arranjo do Estrutura Hierárquica de Sistema (SBS), alguns dos elementos do GSE de sistema podem ser os mesmos utilizados para teste de qualificação/aceitação do subsistema no nível hierárquico abaixo.

Devido ao fato, dos requisitos do GSE estarem fortemente acoplados à solução do produto espacial, a cada evolução na definição no design do produto espacial pode acarretar em nova necessidade de operação ou teste, fazendo com que os requisitos do GSE evoluam (10).

241

5.3.6.6 Realimentação de Requisitos de GSE para Produto Espacial:

Interface (11) e (12) :

Conforme a solução de design do GSE evolui, podem ser necessários redefinição de interfaces ou mesmo a necessidade de funcionalidade adicional no produto espacial (12) para que o elemento do GSE consiga executar um determinado teste ou operação (11). A forma eficiente de as definições de GSE serem disponibilizada é através de modelos e simuladores integrados ao produto espacial. A evolução do design do GSE também pode ser fator de ajustes ao processo de AIT, relacionados a restrições impostas pela solução do GSE ao processo (12).

5.3.6.7 Realimentação de Justificativa de Design: Interfaces (13) e (14):

Simultaneamente aos desenvolvimentos e em consequência da evolução das definições de design do GSE e do processo de AIT, os dossiês de justificação de design (DJF) evoluem. O DJF do produto espacial é complementado pelo DJF do processo de AIT (13) que, por sua vez, é apoiado pelo DJF do GSE (12).

5.4 O Processo de Desenvolvimento Integrado de GSE

O objetivo desta seção é apresentar o processo proposto para desenvolvimento de GSE que integra os processos de desenvolvimento do GSE, do produto espacial, e de seu processo de AIT.

O Processo de Desenvolvimento Integrado de GSE (PDIG) é baseado no Processo de Análise Estruturada de Sistemas (PAES) proposto no Apêndice A que por sua vez é baseado no Método de Análise Estruturada Concorrente de Loureiro em 1999 e 2010 e apresentado na Seção 2.10.

O PDIG é o resultado da aplicação simultânea do PAES ao produto espacial, seu processo de AIT e aos produtos de apoio necessários ao processo de AIT, em especial, o GSE conforme pode ser visto na Figura 5.6.

242

Os processos do ciclo de vida do produto são vistos como funções desempenhadas pela organização que as implementam (LOUREIRO, 2010). Em especial o processo de AIT do produto espacial é uma função desempenhada pela organização responsável pelo AIT. O resultado da análise de implementação dessas funções aponta para estrutura da organização. Ou seja, levantar os requisitos dos processos do ciclo de vida do produto chega-se inexoravelmente à organizações que os implementam respectivamente.

Cabe salientar que o PDIG apresentado nesta dissertação tem como foco e motivador o desenvolvimento do GSE, que é parte dos produtos de apoio ao processo de AIT dentro do ciclo de vida do produto espacial. Dessa forma, não será abordado outros produtos de apoio também importantes para o desenvolvimento do produto final, como por exemplos, os modelos e simuladores desenvolvidos para o processo de Verificação.

Os processos apresentados nesta dissertação seguem as diretivas e processos das normas ISO/IEC15288:2008 e IEEE-STD-1220:2005, com a virtude de trazer para o centro da análise de sistema o desenvolvimento simultâneo dos sistemas de apoio ao processo de AIT (1).

Nota (1): Fazer o desenvolvimento de sistema de apoio simultaneamente com o desenvolvimento do sistema de interesse contradiz a norma EIA-632 (ANSI,2003), que considera que os produtos de apoio somente devem iniciar seu desenvolvimento após o produto final estar completamente definido conforme pode ser observado no trecho abaixo:

“Desenvolvimento dos produtos de apoio são normalmente iniciados após os produtos finais relacionados estarem totalmente definidos e após os requisitos para os produtos de apoio terem sido identificados ” EIA-632 (ANSI,2003,p.48).

As normas ISO/IEC15288:2008, IEEE-STD-1220:2005, EIA-632 (ANSI,2003) e manuais de engenharia de sistemas (NASA,2007) e ISO/IEC-TR-19760:2003) tratam superficialmente do desenvolvimento de sistemas de apoio e elencam atividades relacionadas apenas de forma coadjuvante em relação ao sistema de interesse, e de forma recursiva a norma ISO/IEC15288:2008, apenas considera os sistemas de apoio como um sistemas de interesse quanto estes

243

estão sendo desenvolvidos conforme pode ser observado no fragmento abaixo (ISO/IEC15288:2008):

“Cada sistema de apoio tem seu ciclo de vida próprio. Esta norma internacional é aplicável a cada sistema de apoio, quanto por direito próprio, ele é tratado como um sistema-de-interesse”(ISO/IEC15288:2008).

O objetivo deste trabalho é evidenciar que uma solução eficiente de GSE somente é possível quando desenvolvido simultaneamente com o produto espacial e seu processo de AIT e vice-versa, i.e., a solução do produto espacial somente é possível quando desenvolvido simultaneamente com seus processos do ciclo de vida (incluindo o processo de AIT) e os produtos de apoio necessários (incluindo o GSE).

Este trabalho não tenta relativizar o esforço e a importância do desenvolvimento de sistemas de interesse em contrapartida aos sistemas de apoio, mas reforça o relacionamento do desenvolvimento dos sistemas de apoio dentro do esforço de desenvolvimento do sistema de interesse dado que cada um demanda ao outro requisitos.

O tratamento em conjunto do sistema de interesse e dos sistemas de apoio estão alinhados com as premissas e objetivos da engenharia simultânea e do método de Visão Total de Loureiro (1999).

244

Figura 5.6 – Processo de Desenvolvimento Integrado de GSE.

245

5.4.1 Processo de Análise de Sistema – (Satélite)

O processo de análise de sistema (processo “S” na Figura 5.6) é baseado no

Processo de Análise Estruturada de Sistema – PAES apresentado no Apêndice A, com a inclusão explicita dos processos Análise de Verificação e Análise de Integração no loop de verificação, como início da definição do processo de AIT conforme Figura 5.7.

Figura 5.7 – Processo de Análise de Sistema aplicado ao Produto Espacial (S)

O processo se inicia com o processo de Análise de Missão – S0 onde são

traçados diretivas de alto nível ao sistema e levantados os cenários do ciclo de vida do produto. A Análise de Missão do sistema é composta por 4 atividades conforme detalhado na Seção A.2.

A Análise de Stakeholder do sistema faz-se necessária para que sejam

levantadas todas as suas preocupações em relação ao produto, ao processo e à organização. O processo Análise de Stakeholder – S1 possui basicamente 4 atividades e é detalhada na Seção A.3.

246

A partir do levantamento dos interesses dos stakeholders é possível mapear os requisitos de sistema por meio do processo Análise de Requisitos – S2 detalhado na Seção A.4.

Requisitos de sistema podem ser classificados basicamente em funcionais e

não funcionais: desempenho e condições. Requisitos funcionais e não funcionais são mapeados para a arquitetura funcional por meio do processo de análise funcional detalhado na Seção A.5.

A arquitetura funcional é então alocada a uma solução de arquitetura física por meio do processo de implementação mostrado na Seção A.6.

Adicionalmente ao PAES, são acrescentados os processos de Análise de Verificação (S5) e Análise de Integração (S6), cujos objetivos são diferentes apesar de estarem relacionados.

O objetivo do processo Análise de Verificação (S5) é propor um plano de

verificação que demonstre como o sistema é verificado dentro das restrições existentes incluindo as restrições impostas pelo processo de integração do sistema. O processo de Análise de Verificação é detalhado na Seção 0.

Por outro lado, o objetivo do processo de Análise de Integração (S6) é garantir

que a estratégia de integração do sistema seja progressiva e atenda aos requisitos e restrições impostos pelos subsistemas e pelo processo de verificação do sistema. O processo de Análise de Integração é detalhado na Seção 5.4.1.3.

5.4.1.1 Análise de Implementação (Produto Espacial) – S4

A análise de implementação de um produto espacial balizará o esforço técnico

do processo de AIT. A decomposição do produto espacial em elementos de acordo com a norma IEEE-Std-1220 (2005), i.e. em produtos e processos do ciclo de vida, deve estar coerente com plano de desenvolvimento e definirá a Estrutura Hierárquica do Sistema – SBS do satélite da Figura 5.8.

247

A Figura 5.8 mostra duas opções da Estrutura Hierárquica do Sistema – SBS (System Breakdown Structure) de um satélite. O SBS irá delimitar o plano de desenvolvimento, em como cada elemento será desenvolvido, verificado e integrado ao sistema.

Na opção 1 o esforço técnico do processo de AIT é de integrar e testar todos os subsistemas, incluindo painel solar no processo de AIT do satélite. O processo de transição de cada subsistema garante que o produto subsistema seja entregue testado e pronto para ser integrado ao sistema.

Por outro lado, na opção 2, a estrutura de hierárquica do satélite é formada por

3 produtos apenas: o Módulo de Serviço – SM, o Módulo de Carga-Útil – PM e o painel solar. Esses 3 subsistemas são entregues prontos para serem integrados pela organização responsável pelo processo de AIT do satélite. O SBS da opção 2 possui mais um nível de integração para os módulos SM e PM. Os módulos SM e PM são integrados e verificados a parte, em processos independentes, e posteriormente transicionados para a organização responsável pelo AIT do satélite para que o satélite seja finalmente integrado e testado. A integração do SM e PM pode ser feita pela mesma organização do processo de AIT do satélite, mas é importante que o processo de transição seja executado com rigor para a transferência de responsabilidades sobre os produtos e a formalização da finalização das atividades planejadas para cada nível da estrutura hierárquica.

248

Figura 5.8 – Exemplos de SBS de um Satélite

Portanto o SBS deve ser preparado de acordo com o esforço de integração dos seus produtos decompostos do sistema, delimitando a missão do processo de AIT da Seção 5.4.2.

Um SBS incoerente com o esforço de integração, pode levar a uma definição

técnica da solução do processo de AIT equivocada.

5.4.1.2 Análise de Verificação (Produto Espacial) – S5

O objetivo do Processo de Análise de Verificação (S5) é garantir que a

estratégia de verificação é apropriada e suficiente para que o Processo de

249

Verificação possa garantir que o sistema será construído em acordo com os requisitos de projeto.

O escopo da Análise de Verificação vai além das atividades de testes e inspeção no processo de AIT, já que a verificação de requisitos envolve outros métodos como demonstração e análise.

Do ponto de vista de desenvolvimento de GSE, o processo Análise de Verificação em conjunto com o processo Análise de Integração, mostrado na Seção 5.4.1.3, fornece os requisitos de alto nível necessários para o desenvolvimento da solução de AIT, incluindo seus produtos de apoio: o GSE, a infraestrutura, os procedimentos e treinamentos necessários.

As principais saídas da Análise de Verificação, sob o ponto de vista de desenvolvimento de GSE são:

Plano de Verificação;
Levantamento de cenários de testes; · Matriz de testes;
Identificação da infraestrutura de testes;
Identificação preliminar de elementos do GSE.

A Figura 5.9 mostra as atividades que dão suporte ao processo Análise de

Verificação.

Figura 5.9 – Processo Análise de Verificação de Sistema (S5)

250

5.4.1.2.1 Definir a Estratégia de Verificação – S50

O processo de definição de estratégia de verificação deve analisar os requisitos

de sistema e estabelecer critérios e formas de verificação.

Como saída desse processo pode ser destacado:

Matriz de verificação; · Cenários de Testes.

O método de verificação, isto é, a forma como os requisitos serão verificados, i.e., análise, demonstração, inspeção ou teste, deve ser formalizado e rastreado por meio da matriz de verificação.

Com a matriz de verificação definida, é possível estabelecer condições e os cenários onde os testes e as inspeções devem ocorrer.

Os cenários de testes e inspeções, devem ser analisados em conjunto com os

cenários de integração abordado na Seção 5.4.2.1. Os cenários de testes e inspeções são intercalados aos cenários de integração durante as atividades de AIT do satélite e campanha de lançamento, já que as últimas verificações do satélite são feitas em conjunto com o lançador.

5.4.1.2.2 Identificar Restrições de Verificação – S51

O processo de identificação de restrições de verificação tem como objetivo

levantar possíveis restrições técnicas e logísticas que possam comprometer a verificação dos requisitos de sistema do produto espacial.

As restrições de verificação podem ser oriundas de limitações do processo de verificação tais como precisão dos instrumentos, incertezas do método, dificuldades de acesso, ou oriundas de deficiências do produto como: falta de interfaces específicas para testes, falta de modo de operação específico, eventos de difícil determinação, ou ainda de riscos envolvidos na verificação entre outros.

251

A identificação de restrições de verificação deve servir de realimentação ao processo Análise de Requisitos do produto espacial (S2) e seus subsistemas (SS2) seguindo processo detalhado na Seção A.4.

O produto final, e seus subsistemas, devem possuir interfaces para

investigação e diagnóstico para eventuais dificuldades de verificação integração.

As restrições de verificação devem ser formalizadas em um documento de análise de risco de verificação.

5.4.1.2.3 Definir Plano de Verificação – S52

O objetivo do processo de definição do plano de verificação é definir a matriz de verificação de requisitos do produto espacial, o plano de verificação e os produtos de apoio necessários ao processo de verificação. A saídas do processo são:

Plano de Verificação:

o Estratégia de Verificação; o Matriz de Verificação.

Modelos:

o Definir modelos (ex.: Modelo térmico, estrutural, entre outros.); o Definir os requisitos para desenvolvimento dos modelos.

Simuladores:

o Definir simuladores (ex.: de satélite (TMTC), órbita, entre outros.); o Definir os requisitos para simuladores.

AIT:

o Definir Lista de Testes;

o Identificar GSE necessário (ex.: SCOE TTC);.

5.4.1.3 Análise de Integração (Satélite) – S6

O processo de Análise de Integração tem como objetivo analisar a estratégia de integração, levantar restrições e garantir que a solução de implementação

252

adotada é apropriada e suficiente para que o produto espacial possa ser integrado de forma lógica, progressiva, eficiente e segura.

A Figura 5.10 mostra as atividades que dão suporte ao processo Análise de Integração.

O processo de Análise de Integração é fortemente acoplado ao processo de Análise de Verificação (S5) e deve ser analisado em conjunto e simultaneamente. Ambos os processos (S5 e S6) tem objetivos distintos mas estão intrinsicamente conectados e são aplicados pela organização desenvolvedora do produto espacial.

O processo de análise de integração (S6) juntamente com o processo de análise de verificação (S5) são simultaneamente aplicados com o processo de análise de AIT do produto espacial (A) , apresentado na Seção 5.4.2 deste capítulo, cujo objetivo é propor uma solução de AIT para o produto espacial.

Figura 5.10 – Processo Análise de Integração de Sistema (S6)

5.4.1.3.1 Definir a Estratégia de Integração – S60

A definição da estratégia de integração deve estar em acordo com a estratégia

de verificação e que atenda aos requisitos de verificação.

A definição da estratégia de integração deve ser feita o quanto antes para que possibilite o desenvolvimento simultâneo das ferramentas e processos necessários.

253

A definição da estratégia de integração tem início com o levantamento dos cenários de montagem e integração dos elementos e subsistemas do produto espacial, oriundos do processo de implementação (S4), onde elementos e subsistemas são definidos.

A Integração do produto espacial deve seguir uma sequência lógica, progressiva para que o sistema possa ser integrado de forma eficiente. A definição da estratégia de integração deve estar em acordo com o plano de desenvolvimento e cronograma de disponibilidades dos subsistemas e elementos que compõe o produto espacial.

5.4.1.3.2 Identificar Restrições de Integração – S61

O processo de identificação de restrições de integração tem como objetivo

levantar possíveis restrições técnicas, logísticas e organizacionais que possam comprometer a integração dos elementos e subsistemas do produto espacial.

As restrições de integração podem ser oriundas de limitações de design, como acessibilidade, falta de interfaces para sistemas de apoio (MGSE), sequência inadequada, entre outras.

A identificação de restrições de integração deve servir de realimentação ao processo Análise de Requisitos do produto espacial (S2) e seus subsistemas (SS2) seguindo processo de análise de requisitos detalhado na Seção A.4.

O produto final, e seus elementos e subsistemas, devem possuir interfaces apropriadas a sua integração com o sistema.

As restrições de integração devem ser formalizadas em um documento de análise de risco de integração.

5.4.1.3.3 Definir Plano de Integração – S62

O objetivo do processo de definição do plano de integração é, definir o modelo

de arborescência e a sequência de integração do produto espacial. O modelo de arborescência do produto espacial em conjunto com a matriz de testes, identificado no processo de Análise de Verificação (processo “S5” Figura 5.6).

254

serão as entradas para a determinação dos estados de integração do produto espacial definido no processo de análise do AIT (processo “A” da Figura 5.6). No processo de definição do plano de integração também são definidas as listas de agregáveis, i.e. os kits de montagem (parafusos, porcas, arruelas, espaçadores), os materiais necessários (colas e graxas térmicas) e os produtos de apoio necessários ao processo de integração. A lista abaixo mostra as saídas do processo:

Modelo de arborescência42do sistema; · Simuladores – identificar simuladores;
GSE necessário (ex.: MGSE, suportes, entre outros); · Requisitos de integração.

5.4.2 Processo de Análise de AIT (Satélite em AIT)

O objetivo do processo de análise de AIT (processo “A” na Figura 5.6) é definir

uma solução de AIT que possa integrar e testar de forma segura e eficiente o produto espacial, cumprindo os requisitos de verificação e integração levantados no processo de análise de verificação (S5) e no processo de análise de integração (S6).

O processo de análise de AIT é aplicado pela organização desenvolvedora do AIT e deve ser aplicado simultaneamente aos processos de análise de verificação (S5) e análise de integração (S6) descritos nas seções 0 e 5.4.1.3 respectivamente.

O processo de análise de missão AIT (A0) é simbioticamente relacionado ao processo de análise de integração (S6) e ao processo análise de verificação (S5) respectivamente numa relação de mutualismos, onde um processo depende do outro. Enquanto o processo de AIT de sistema (Processo A) trabalha no domínio da solução os processos mútuos de análise de integração

42 O modelo de arborescência é a principal entrada para definição dos estados do satélite em AIT. Os estados do satélite em AIT descrevem os estados do produto espacial em conjunto com GSE.

255

(S6) e análise de verificação (S5) trabalham no domínio do problema, impondo requisitos e condições que delimitam o universo de soluções.

Figura 5.11 – Processo de Análise de AIT (A)

O processo de análise de AIT é derivado do Processo de Análise Estruturada de Sistema – PAES apresentado no Apêndice A e ajustado para o Processo de AIT que possui 5 sub-processos:

Processo de Análise de Missão de AIT – A0
Processo de Análise de Stakeholders de AIT – A1 · Processo de Análise de Requisitos de AIT – A2
Processo de Análise Funcional de AIT – A3 · Processo de Análise de Implementação – A4

5.4.2.1 Processo de Análise de Missão de AIT – A0

O processo de análise de missão de AIT (A0) tem como objetivo propor possíveis conceitos para montagem, integração e testes mas que estejam de acordo com a estratégia de integração levantada no processo S60 e com a estratégia de verificação levantada no processo S50.

A definição da estratégia de integração tem início com o levantamento dos cenários de montagem, integração e testes do produto espacial, e deve seguir uma sequência lógica, progressiva, eficiente e que esteja aderente aos requisitos estabelecidos.

256

5.4.2.2 Processo de Análise de Stakeholders de AIT – A1

O processo de análise de stakeholders de AIT (A1) tem como objetivo levantar todos os possíveis stakeholders para as atividades planejadas nos conceitos de AIT preparado pelo processo de análise de missão de AIT (A0).

O processo de análise de stakeholders de AIT segue o processo homônimo do

Processo de Análise Estruturada de Sistema – PAES apresentado na Seção A.3 para processos e possui 4 sub-processos:

Identificar os stakeholders de AIT e suas preocupações;

Organizar os stakeholders de AIT de acordo com suas preocupações; · Identificar os requisitos dos stakeholders;
Identificar as medidas de efetividades MoEs.

5.4.2.3 Processo de Análise de Requisitos de AIT – A2

O processo de análise de requisitos de AIT (A2) tem como objetivo validar e compilar os requisitos do processo de AIT advindos do sistema, pelos processos de análise de verificação (S5) e processo de análise de integração (S6) e pelos requisitos advindo dos stakeholders de processo identificados no processo de análise de stakeholder de AIT (A1).

O processo de análise de requisitos de AIT segue o processo homônimo do

Processo de Análise Estruturada de Sistema – PAES apresentado na Seção A.4 para processos e possui os seguintes sub-processos:

Organizar os pressupostos; · Organizar os requisitos;
Compilar o dossiê de requisitos;

Validar os requisitos de processo.

257

5.4.2.4 Processo de Análise Funcional de AIT – A3

O processo de análise funcional de AIT tem como objetivo propor uma solução de AIT que atenda aos requisitos compilados e validados do processo de análise de requisitos de AIT (A2).

O processo de análise funcional de AIT segue o processo homônimo do

Processo de Análise Estruturada de Sistema – PAES apresentado na Seção A.5 para processos e possui os seguintes sub-processos:

Identificar as fronteiras do processo de AIT;

Definir fases do processo de AIT e os estados e modos do produto espacial durante o processo de AIT;
Identificar os riscos do processo;

Propor a sequência das atividades;

Definir os atributos dos recursos necessários;

Definir os procedimentos necessários para o processo;

Validar processo de AIT: validar a sequência e os recursos necessários.

5.4.2.5 Processo de Análise de Implementação – A4

O processo de análise de implementação de AIT (A4) tem como objetivo propor uma implementação que atenda a arquitetura de AIT definida no processo de análise funcional de AIT (A3).

Segundo Loureiro (2010), os processos do ciclo de vida do produto são as funções desempenhadas pela organização desenvolvedora, ou seja, a análise de implementação do processo de AIT fornece arquitetura física da organização desenvolvedora de AIT.

O processo de análise de implementação de AIT segue o processo homônimo do Processo de Análise Estruturada de Sistema – PAES apresentado na Seção A.6 para processos e possui os seguintes sub-processos:

Identificar os elementos (físicos) da organização desenvolvedora; · Identificar e especificar os recursos necessários: pessoal, GSE,

258

infraestrutura, treinamento etc;

Alocar os processos de AIT (funções) às equipes e departamentos da organização desenvolvedora (arquitetura física), PBS, WBS;
Identificar as interfaces do processo de AIT – determinar os produtos de apoio de design conforme Seção 5.3.6);
Estabelecer a arquitetura física da organização desenvolvedora do processo de AIT;
Verificar e validar a arquitetura física.

5.4.3 Processo de Análise de GSE de Sistema – (Satélite)

O objetivo do processo de análise de GSE de sistema (processo “G” na Figura 5.6) é propor um solução de GSE para dar suporte ao produto espacial durante o processo de AIT.

Figura 5.12 – Processo Análise de e GSE de Sistema (G)

O processo de análise de GSE é derivado do Processo de Análise Estruturada

de Sistema – PAES apresentado no Apêndice A e possui os seguintes sub-processos:

Análise de Missão (GSE) – G0;
Análise de Stakeholder (GSE) – G1; · Análise de Requisitos (GSE) – G2;

259

Análise Funcional (GSE) – G3;
Análise de Implementação (GSE) – G4.

5.4.3.1 Análise de Missão (GSE) – G0

O Objetivo do processo de análise de missão de GSE (G0) é determinar em

linhas gerais os objetivos do GSE demandando bem como seu ciclo de vida.

O processo de análise de missão do GSE, aplicado pela organização responsável pelo desenvolvimento do GSE, é mutuamente relacionado com o processo de implementação do AIT (A4) aplicado pela organização desenvolvedora do processo de AIT. O mutualismo desses processos está no escopo de definição da missão e requisitos de GSE de alto nível.

A análise de missão do GSE segue o processo homônimo do Processo de Análise Estruturada de Sistema – PAES descrito na Seção A.2.

Uma das saídas do processo é o levantamento dos cenários operacionais e não operacionais relevantes do GSE.

5.4.3.2 Análise de Stakeholder (GSE) – G1

O processo de análise de stakeholder de GSE (G1) tem por objetivo levantar todos os possíveis stakeholders de produto, processo e organização suas preocupações para o GSE.

O processo Análise de Stakeholder de GSE possui basicamente 4 atividades e

é detalhada na Seção A.3:

Identificar os Stakeholders e suas preocupações;
Organizar as preocupações para produto, processo e organização; · Identificar os requisitos dos stakeholders;
Identificar as medidas de efetividades – MoEs dos stakeholders;

Dentre os stakeholders de GSE estão os stakeholders do produto espacial, os stakeholders do processo de AIT, os stakeholders organizacionais e

260

stakeholders externos como normas, e manuais de infraestrutura e bases de lançamento.

5.4.3.3 Análise de Requisitos (GSE) – G2

O processo de análise de requisitos de GSE (G2) tem por objetivo definir os requisitos técnicos que descrevam por completo o GSE.

Os requisitos de stakeholders e as correspondentes medidas de efetividade MoEs levantados no processo de análise de stakeholders de GSE (G1) são analisados, traduzidos e mapeados para requisitos técnicos do GSE por meio do processo Análise de Requisitos detalhado na Seção A.4. Ao final desse processo dois documentos são elaborados:

documento de especificação técnica do produto GSE;

documento de especificação de processos do ciclo de vida do GSE.

Durante o processo de análise de requisitos deve ser considerado também a padronização das soluções de GSE adotada em outros projetos ou programas. Soluções de projetos de GSE anteriores, interfaces comuns e soluções consolidadas devem ser analisadas durante o processo de análise de requisitos. A padronização entre projetos tem como stakeholder a organização desenvolvedora do AIT e deve olhar em perspectiva continuada de projetos, conforme Figura 5.14.

O processo de análise de requisitos deve ser periodicamente revisitado devido aos loops internos previstos no PAES tais como o “loop de requisitos” e o “loop de verificação”, bem como aos loops externos do PDIG tais como: “loop de processo”, “loop de acoplamento funcional” conforme pode ser observado na Figura 5.13.

A revisita ao processo de análise de requisitos de GSE (G2) resulta na evolução dos documentos de especificação de requisitos do GSE em baselines planejadas que permite a troca de informação entre as organizações

261

desenvolvedoras do produto espacial, do processo de AIT e do GSE, conforme abordado na Seção 5.3.1.2.

5.4.3.4 Análise Funcional (GSE) – G3

O objetivo do processo de análise funcional de GSE (G3) é propor uma arquitetura funcional ao GSE.

O processo de análise funcional segue o processo homônimo do PAES detalhado na Seção A.5 e possui 6 atividades:

Identificar as fronteiras do GSE e suas interfaces;
Definir os estado e modos do GSE (ex. Configuração do EGSE para teste fase A, configuração do EGSE para lançamento, entre outros);
Definir as funções;
Analisar o comportamento funcional – incluindo funções de perigo (ex.: redundância, modo manual, entre outros);
Estabelecer arquitetura funcional; · Definir atributos funcionais;
Verificara arquitetura funcional.

O processo de análise funcional deve ser periodicamente revisitado para garantir que a solução de design do produto espacial esteja contemplado na solução de design do GSE. Esse acoplamento funcional, descrito na Seção 5.4.4.1 será posteriormente traduzido em requisitos do GSE pelo “loop de requisitos”.

5.4.3.5 Análise de Implementação (GSE) – G4

O objetivo da análise de implementação de GSE (G4) é propor uma arquitetura física ao GSE a partir da arquitetura funcional resultante do processo de análise funcional (G3).

O processo de análise de implementação de GSE segue o processo homônimo

do PAES mostrado na Seção A.6 e possui as seguintes atividades:

Identificar os Elementos Físicos do EGSE e MGSE (ex.: PSS SCOE, OCOE, entre outros);
Alocar Funções aos Elementos Físicos (ex.: Alimentação do satélite provida pelo PSS SCOE);

262

Identificar as Interfaces Físicas (interfaces entre SCOEs, interfaces com o satélite, entre outros.);
Estabelecer uma Arquitetura Física;

Verificar Arquitetura Física – verificar se todos os requisitos estão contemplados na solução física;
Derivar Arquitetura Física – Definir os elementos para o nível abaixo; · Rever alocação Física baseado na implementação nos GSEs dos

subsistemas (loop de reuso).

A análise de implementação deve considerar a possibilidade de reuso dos sistemas de testes de subsistema ao nível acima i.e., ao processo de AIT. Essa relação aparece no “loop de reuso” da Figura 5.13.

5.4.4 Loops Externos

O diferencial do Processo Integrado de Desenvolvimento de GSE é que o processo de desenvolvimento do produto espacial, de seu AIT e do GSE são analisados em uma ótica mais aberta e portanto permitindo que os processos de análise de sistema de cada um dos 3 elementos da tríade interaja não apenas na entrada e saída do processo de análise de sistema apresentado no Apêndice A, mas também entre seus sub-processos.

O diagrama da Figura 5.13 mostra em destaque os loops externos entres os processos de análise da tríade de elementos do sistema.

263

Figura 5.13 – Loops Externos do Processo de Desenvolvimento Integrado do GSE

5.4.4.1 Loop de AIT

O “loop de AIT” está relacionado com a definição do estado (de integração) com que o subsistema é entregue para o AIT do sistema. As atividades de AIT podem mudar substancialmente de escopo dependendo de como o subsistema é entregue conforme discussão da Seção 5.4.1.1.

Um exemplo de loop de AIT é a entrega para AIT do subsistema TT&C, no qual, apesar de o subsistema ser entregue completo, incluindo os cabos de RF, as unidades e cabos são entregues desmontados para serem integrado ao

264

satélite, necessitando assim de validação de suas interfaces e com isso repetir testes de performance.

O diagrama de captura ontológica do satélite apresentado na Figura 5.4 pode não capturar por completo essa informação. O manual de instalação do subsistema deve descrever como o subsistema é entregue e montado ao satélite, incluindo um diagrama de captura ontológica do subsistema.

5.4.4.2 Loop de Acoplamento Funcional

O “loop de acoplamento funcional” está relacionado com as características da solução do produto espacial que é acoplada as características da solução do GSE. Essas características da solução do produto espacial não podem ser especificadas como requisitos no momento da identificação do elemento do GSE conforme discutido nas Seções 1.1.1 e 5.3.6.5.

O loop de acoplamento funcional juntamente com o loop de requisitos permite que a revisita periódica ao processo de análise de requisitos do GSE (G2) possa capturar as necessidades técnicas do GSE possibilitando assim a evolução da baseline de especificação técnica do GSE.

5.4.4.3 Loop de Acoplamento de Processo

O “loop de acoplamento de processo” esta relacionado com a dependência da

das características das mecanismos (o GSE é um mecanismo) à definição do processo.

As definições do processo de AIT não podem ser descritas por completo no momento da identificação da necessidade do GSE.

Um exemplo de loop de acoplamento de processo é observado no OCOE, o elemento central do EGSE, pois os scripts de testes somente podem ser definidos em conjunto com os procedimentos de testes.

265

5.4.4.4 Loop de Reuso

O loop de reuso esta relacionado com a sobreposição de funcionalidade a dois níveis da hierarquia do GSE e portanto a possibilidade de utilização ou adaptação do GSE de subsistema para uso no AIT de sistema.

A sobreposição de função acontece porque a hierarquia da estrutura do

produto de apoio não segue em paralelo à hierarquia do produto espacial. Ou seja, uma função alocada ao subsistema necessita de um GSE para teste a nível de subsistema e também necessita de um GSE para operar e possivelmente re-testar a função no nível de sistema, necessitando assim da mesma funcionalidade no GSE de sistema.

O loop de reuso acopla os processos de definição da arquitetura física do GSE de sistema e de subsistem. Posteriormente e graças ao loop de design e loop de requisitos, a especificação do GSE revisitada através do processo de análise de requisitos de GSE (G2)

Um exemplo dessa sobreposição de funcionalidade de GSE acontece com o subsistema PSS que necessita de simulador de painel solar – SAS (Solar Array Simulator) para os testar a função “converter a energia do painel solar para o barramento” a nível de subsistem. Ocorre que a mesma função deve ser verificada também a nível de sistema, ou seja após a integração do subsistema PSS ao satélite é necessário um teste dessa função com o SAS.

Apesar de as funções básicas serem praticamente as mesmas para os dois SAS demandados, algumas diferenças existem, como por exemplo a função de controle remoto do GSE. Essa função é necessária para os testes a nível de sistema, mas pode não ser necessário nem conveniente para os testes a nível de subsistema.

266

5.4.4.5 Padronização Entre Projetos

A padronização entre projetos está relacionada com heranças técnicas de projetos que tiveram sucesso no passado, e com a reutilização em projetos futuros com o objetivo de reduzir custos.

O loop de padronização entre projetos está alinhado com a abordagem de

sistemas abertos da Seção 5.3.2. Nessa abordagem a escolha de interfaces e elementos da arquitetura funcional e física são considerados em uma perspectiva mais ampla, além da fronteira do projeto, visando a utilização em projetos futuros como forma de redução de custos em desenvolvimento.

A padronização de soluções para GSE não somente reduz custo de

desenvolvimento futuro como também reduz custo de treinamento de pessoal em diversos sistemas, reduz custo de aquisição de ferramentas de desenvolvimento, reduz tempo de aprendizagem nas ferramentas, reduz custos relacionados a logísticas complexa de GSE específico para cada projeto, entre outros.

Os benefícios de soluções padronizadas entre projetos são inúmeros, porém o desenvolvimento de soluções gerais, em contrapartida de uma solução específica, pode aumentar o custo do desenvolvimento já que funcionalidades adicionais devem ser implementada, como por exemplo, função de configuração de parâmetros.

A organização desenvolvedora do GSE deve negociar com a organização responsável pelo processo de AIT a solução desejada.

267

Figura 5.14 – Padronização de GSE entre Projetos

5.4.5 Processos de Análise de Subsistema

O processo de análise de subsistema (processo “SS” na Figura 5.6) segue as mesmas recomendações de aplicação ao processo de análise aplicado ao sistema (processo “S) com a diferença de que o processo de análise de missão (SS0) é parcialmente compartilhado com o processo de análise de implementação (S4) aplicado ao sistema (nível acima na hierarquia do produto) pela organização desenvolvedora. A Figura 5.15 mostra o processo análise de subsistema com mais detalhes.

268

Figura 5.15 – Processo Análise de Subsistema (SS)

5.4.6 Processo de Análise de AIT de Subsistema

O processo de análise de AIT de subsistema (processo “AS” na Figura 5.6) segue as mesmas recomendações de aplicação ao processo de análise AIT do sistema (processo “A”) com a diferença de que o processo de AIT do subsistema não é uma decomposição do processo de AIT do subsistema.

De fato, a relação é oposta já que a definição do processo de AIT do subsistema (AS) irá afetar a definição do processo de AIT do sistema (A).

A Figura 5.16 mostra o processo análise de AIT de subsistema em com mais

detalhes.

269

Figura 5.16 – Processo Análise de AIT de Subsistema (AS)

5.4.7 Processo de Análise de GSE de Subsistema

O processo de análise de GSE do subsistema está relacionado com o segundo nível da estrutura hierárquica do GSE, i.e. como os elementos de GSE identificados na análise do processo de AIT.

A estrutura da hierarquia do GSE pode ser fortemente influenciada pela estrutura da hierarquia do produto espacial, já que para cada subsistema deve haver um GSE específico para apoio à atividades de montagem e testes do subsistema. Porém o GSE de subsistema para uso no processo de AIT do sistema não necessariamente precisa seguir a estrutura dos subsistemas do produto espacial. Exemplo disso é o subsistema OBDH do CBERS mostrado na Seção 4.2.6, que possui um EGSE próprio para os testes de subsistema mas os elementos do EGSE usados no processo de AIT do satélite são o OCOE e a Estação de TM & TC.

Para mais detalhes sobre a correlação da implementação do EGSE com os SCOEs veja a discussão sobre “loop de reuso” da Seção 5.4.4.4.

270

Figura 5.17 – Processo Análise de GSE de Subsistema (GS)

271

272

6 Aplicação do Guia de Desenvolvimento Integrado de GSE

O objetivo deste capítulo é aplicar o Guia de Desenvolvimento Integrado de GSE proposto no capítulo 5 para demonstrar sua relevância no desenvolvimento de um elemento do GSE.

6.1 Introdução

O Guia de Desenvolvimento Integrado de GSE proposto no Capítulo 5 desta dissertação, tem como fundamentos a aplicação dos processos de engenharia de sistemas simultaneamente aplicada ao desenvolvimento produto espacial, seu processo de AIT e o GSE, bem como na relação entre suas organizações desenvolvedoras. O guia também recomenda a aplicação do conceito de sistemas abertos ao projeto do GSE como forma de minimizar riscos de desenvolvimento e garantir que a solução de design seja versátil para evoluir em função do evolução dos requisitos, que conforme visto na Seção 1.1.1.

Apoiado nesses fundamentos o guia propõe o Processo de Desenvolvimento Integrado de GSE – PDIG, na Seção 5.4, como uma tentativa de correlacionar os desenvolvimentos do produto espacial, seu processo de AIT e o GSE. Dessa forma, o PDIG proporciona uma visão sistêmica privilegiada da interdependência dos processos de análise de sistemas aplicados simultaneamente à tríade de elementos: produto espacial, seu processo de AIT e o GSE.

Devido a sua abrangência, a aplicação do PDIG envolve muitas organizações desenvolvedoras, grande quantidade de tarefas e extensa produção de produtos de apoio ao design (modelos, diagramas e documentos) que progressivamente e simultaneamente definem e detalham as soluções de design para produto espacial, o processo de AIT e finalmente o GSE.

Conforme os processos são executados simultaneamente nas organizações desenvolvedoras envolvidas, muitos produtos de apoio gerados são trocados entre essas organizações, tornando a demonstração completa do PDIG muito

273

extensa e portanto extrapolando o escopo deste capítulo que é demonstrar o desenvolvimento de um elemento do GSE.

Para que se possa atingir o objetivo desta demonstração, a aplicação do PDIG será focada na aplicação do processo de análise em um elemento do GSE escolhido, e mais alguns processos correlacionados conforme destacado em vermelho na Figura 6.1. Dessa forma a aplicação do processo será seletiva e não extensiva, destacando os produtos de apoio de design relevantes para atingir os objetivos desta demonstração.

A demonstração será feita sobre um EGSE hipotético para o satélite Amazonia-

1. Para isso foi selecionado o SCOE chamado aqui de “Umbilical” e referenciado no resto desta dissertação de “UMB SCOE”. Esta escolha foi motivada devido ao atual estágio de desenvolvimento que se encontra o EGSE real do satélite Amazonia-1, do qual muitos dos seus elementos estão em fase de concepção como é o caso do SCS SCOE, que é o SCOE equivalente ao UMB SCOE desta aplicação.

Na Seção 7.2 será apresentada um comparação entre as duas soluções como forma de demonstrar a aplicabilidade do PDIG.

274

Figura 6.1 – Processos do PDIG aplicados no desenvolvimento do UMB SCOE

Destaque dos processos exercitados para a aplicação do PDIG no desenvolvimento do UMB SCOE

Este capítulo está organizado da seguinte forma:

Na Seção 6.2 é mostrado parte da aplicação do processo de análise de sistema ao produto espacial, i.e., ao satélite Amazonia-1.

Na Seção 6.3 é mostrado parte da aplicação do processo de análise no processo de AIT do satélite Amazonia-1.

275

Na Seção 6.4 é mostrado parte da aplicação do processo de análise ao GSE do satélite Amazonia-1.

E finalmente na Seção 6.5 é mostrado com mais detalhes o processo de análise do UMB SCOE.

6.2 Processo de Análise de Sistema do Satélite (S)

Esta seção mostra parte da aplicação do processo de análise de sistema ao satélite Amazonia-1, com o objetivo de derivar requisitos para o GSE.

Por simplificação em prol da objetividade desta aplicação, o processo de análise de sistema do satélite Amazônia cobre superficialmente o processo de análise de missão (S0), com o objetivo de determinar dos estágios do ciclo de vida, o processo de análise de verificação (S5) e o processo de análise de integração (S6) que fornecem as principais entradas para o processo de análise de AIT da Seção 6.3.

6.2.1 Cenários do Ciclo de Vida do Satélite

Os cenários do ciclo de vida do satélite são determinados pelo processo de Análise de Missão do satélite (processo S0 da Figura 6.1). Um dos objetivos do processo de análise de missão é identificar os cenários do ciclo de vida e identificar quais estão dentro do esforço do desenvolvimento.

O ciclo de vida completo do satélite é mostrado na Figura 6.2, com destaque em verde para os estágios de AIT (S200) e lançamento (S300) que estão dentro do esforço de desenvolvimento da organização desenvolvedora do AIT abordado com mais detalhes na Seção 6.3.

Figura 6.2 – Ciclo de Vida do Satélite

Ciclo de vida do satélite com destaque para os cenários dentro do escopo do desenvolvimento da organização desenvolvedora do AIT.

276

A organização desenvolvedora do satélite prossegue com os demais processos de análise de sistema: análise de stakeholders (S1), análise de requisitos (S2), análise funcional (S3) e análise de implementação (S4), onde são propostos a arquitetura funcional e física, respectivamente.

A arquitetura funcional é a solução de projeto que atende aos requisitos técnicos ao passo que a arquitetura física é a alocação da arquitetura funcional a uma arquitetura física possível e tem como saída a identificação dos produtos e seus requisitos para o nível abaixo na hierarquia de sistema, i.e. os subsistemas conforme Figura 6.3.

Figura 6.3 – Árvore de Produtos dos Satélite Amazonia-1

6.2.2 Análise de Verificação do Satélite (S5)

Simultaneamente aos processos de análise funcional e análise de implementação, o processo de análise de requisitos é revisitado por meio do loop de requisitos e do loop de verificação como resultado dos processos de análise de verificação (S5) e de integração (S6).

O processo de análise de verificação (Processo S5 na Figura 6.1), descrito na Seção 0, tem como objetivo garantir o atendimento a todos os requisitos do sistema.

Para atingir esse objetivo, todos os requisitos técnicos do satélite levantados são mapeados por meio da matriz de verificação onde cada requisito do sistema é verificado por um dos seguintes métodos conforme norma IEEE-Std-1220:2005 descritos em 2.3.7.6:

277

Análise (incluindo modelagem e simulação); · Demonstração;
Inspeção; · Testes.

Da matriz de verificação são derivados os cenários de testes.

Para cada cenário de teste identificado, requisitos de testes são especificados e compilados em documentos de especificação de testes, organizados por testes de subsistemas, testes de arquiteturas e testes de sistemas.

É importante observar que os processos de análise de verificação (S5) e

análise de integração (S6) são simultaneamente aplicados pela organização desenvolvedora do satélite, com envolvimento progressivo da organização desenvolvedora de AIT por meio do processo de análise de AIT (Processo A) conforme Figura 6.1 e detalhado na Seção 6.3.

6.2.3 Análise de Integração do Satélite (S6)

O objetivo do processo de análise de integração (Processo S6 na Figura 6.1) é

garantir que o satélite seja integrável, conforme descrito na Seção 5.4.1.3.

Para isso, modelos do satélite e das unidades são fornecidos e integrados em conjunto com todas as ferramentas e infraestrutura necessárias identificadas.

O processo de análise de integração (S6) é simultaneamente aplicado com o

processo de análise de AIT (Processo A) conforme Figura 6.1 e detalhado na Seção 6.3.

6.3 Análise do Satélite em AIT (A)

Esta seção demonstra parcialmente a aplicação do processo de análise ao processo de AIT (Processo A na Figura 6.1), com o objetivo apenas de derivar requisitos para o GSE.

Por simplificação em prol de objetividade desta demonstração, o processo de

análise cobre apenas o processo de análise de missão (A0).

278

Os estágios do ciclo de vida do satélite: processo de AIT (S200) e lançamento (S300) da Figura 6.4 são então decompostos em cenários pelo processo Análise de Missão de AIT (Processo A0 na Figura 6.1).

É importante observar que os processos: A0 – Análise de Missão de AIT, S50 –

Definir estratégia de Verificação e S60 – Definir estratégia de Integração, destacados na Figura 6.1, são processos acoplados entre si e são executados concorrentemente pelas respectivas organizações desenvolvedoras do processo de AIT e do satélite (processos S50 e S60).

A decomposição dos cenários de AIT e lançamento do satélite serão as

entradas para o processo de análise de EGSE na Seção 6.4.

Figura 6.4 – Decomposição dos Cenários de AIT e lançamento do Satélite

6.4 Análise do GSE (G)

O objetivo desta seção é demonstrar resumidamente parte da aplicação do

processo de análise do GSE (Processo G na Figura 6.1).

279

Por terem funções bastante distintas, GSEs de satélite normalmente são divididos por área de conhecimento mecânico e elétrico, respectivamente, o MGSE e o EGSE.

Para esta demonstração o processo de análise será focado em um dos

elemento do EGSE: o Umbilical SCOE ou UMB SCOE.

A partir da decomposição dos cenários de AIT, na análise de missão do EGSE são identificados os cenários operacionais do EGSE. A Figura 6.5 mostra os cenários do processo de AIT relevantes, destacados em verde na figura onde são necessários o suporte do EGSE.

Figura 6.5 – Cenários Relevantes para EGSE no ciclo de vida do satélite

Nota: Os cenários demarcados em vermelho denotam contextos operacionais relevantes do EGSE que são analisados em conjunto.

A análise dos cenários decompostos do processo de AIT da Figura 6.5 apontam, numa primeira passada a apenas 4 contextos operacionais relevantes conforme destacado na Figura 6.5 e listados abaixo:

Integração e Testes Iniciais do Módulo de Serviço – SM;

Integração e Testes Iniciais do Satélite; 3. Testes do Satélite – Caso Geral;

280

Satélite na Torre de Lançamento.

Cada um dos contextos relevantes do EGSE, identificados na Figura 6.5, é analisado por meio dos diagramas de contexto do EGSE mostrados da Figura 6.6 à Figura 6.9.

O processo de análise do EGSE deve ser revisitado cada vez que haja detalhamento das definições dos cenários de AIT e dos elementos do EGSE.

Figura 6.6 – Diagrama de Contexto do EGSE no Cenários S203:Integração e Testes Iniciais do Módulo de Serviço – SM

281

Figura 6.7 – Diagrama de Contexto do EGSE no Cenários S205: Integração e Testes Iniciais do Satélite

282

Figura 6.8 – Diagrama de Contexto do EGSE nos Cenários Relevantes de AIT: Caso Geral

283

Figura 6.9 – Diagrama de Contexto do EGSE no Cenário S307: Satélite na Torre de Lançamento

284

6.5 Análise do UMB SCOE

6.5.1 Análise da Missão do UMB SCOE

A análise de missão do UMB SCOE é feito em conjunto pela organização desenvolvedora do EGSE e pela organização desenvolvedora do UMB SCOE, conforme processo GS0 da Figura 6.1.

Conforme a decomposição do EGSE feita na análise de implementação (G4) a missão alocada ao UMB SCOE é:

Missão: “O Umbilical SCOE será o único elemento do EGSE conectado diretamente ao satélite que possibilite operar, alimentar e monitorar seus sinais vitais durante a fases de AIT e lançamento”.

Juntamente com a definição da missão são definidos necessidades e os possíveis os possíveis conceitos de operação o UMB SCOE conforme Figura 6.10.

Figura 6.10 – Conceito de Operações do UMB SCOE para Enlace de Telemetria e Telecomando

285

6.5.1.1 Ciclo de Vida do UMB SCOE

O ciclo de vida do UMB SCOE é mostrado na Figura 6.11. Os estágios do ciclo de vida relevantes para a organização desenvolvedora do UMB SCOE estão destacados em verde na Figura 6.11.

Figura 6.11 – Ciclo de vida do UMB SCOE

6.5.1.2 Cenários do Ciclo de Vida do UMB SCOE

Para cada estágio do ciclo de vida são derivados cenários conforme a Figura 6.12.

Figura 6.12 – Cenários Relevantes do Ciclo de Vida do UMB SCOE

Na análise dos cenários do ciclo de vida do UMB SCOE, são selecionados os cenários que fazem parte do esforço de desenvolvimento da organização desenvolvedora, e cenários relevantes do ciclo de vida do produto conforme destacados na Figura 6.12 e listados abaixo:

1) Cenários dentro do esforço de desenvolvimento da organização responsável pelo desenvolvimento do UMB SCOE:

U0: Desenvolvimento UMB SCOE;
U11: Fabricação/Aquisição de componentes; · U12: Montagem e integração;
U13: Verificação do UMB SCOE;

286

U2: Transição UMB SCOE;
U35: Operação – Manutenção do UMB SCOE.

2) Cenários relevantes porém fora do esforço de desenvolvimento da organização responsável pelo desenvolvimento do UMB SCOE:

U31: Validação do UMB SCOE;
U32: Operação em AIT do UMB SCOE;
U33: Operação do UMB SCOE em Lançamento do satélite; · U34: Aferição e calibração do UMB SCOE;
U36: Transporte UMB SCOE;
U4: Descomissionamento do UMB SCOE;

Os cenários relevantes dentro do esforço de desenvolvimento (1) serão

analisados pela organização desenvolvedora do UMB SCOE. Para estes cenários serão analisados e derivados requisitos para o produto UMB SCOE e para os processos. A análise dos requisitos é mostrado na Seção 6.5.2.4.

Os demais cenários relevantes mas que estejam fora do esforço de

desenvolvimento, são analisados e derivados requisitos apenas para o produto UMB SCOE. Os demais cenários não são analisados.

6.5.2 Análise de Stakeholder do UMB SCOE – GS2

O processo de Análise de Stakeholder aplicado ao UMB SCOE segue o processo descrito na A.3.

6.5.2.1 Identificação dos Stakeholders de Produto e Processo UMB SCOE

A identificação dos stakeholders de produto e processo é feita para cada cenário do ciclo de vida do UMB SCOE. Esse levantamento é feito por meio de diagramas DFD de contexto onde o produto final, o UMB SCOE, é colocado no centro do diagrama, rodeados pelos stakeholders que são afetados diretamente, stakeholders de produto, e pelos stakeholders de processo que são responsáveis pela origem/destino de entradas, saídas, controles e mecanismos, conforme mostrado da Figura 6.13 à Figura 6.24.

287

As flechas que interligam o produto aos stakeholders mostram as preocupações de cada stakeholder. O sentido da flecha é irrelevante.

Os diagramas foram construídos de forma a organizar os stakeholders e as organizações envolvidas em todos os processos. A cor verde-claro é utilizada para destacar o esforço de desenvolvimento da organização desenvolvedora do UMB SCOE. As cores cinza-claro mostram outras organizações envolvidas no ciclo de vida do UMB SCOE.

No final deste processo, 110 stakeholders foram levantados em 12 cenários do ciclo de vida resultando no total de 35 stakeholders diferentes identificados conforme mostra a Tabela 6.1.

Tabela 6.1 – Dicionário de Stakeholders do UMB SCOE

288

Figura 6.13 – Stakeholders de Produto e Processo para Desenvolvimento UMB

Figura 6.14 – Stakeholders de Produto e Processo para Fabricação/Aquisição de componentes do UMB SCOE

289

Figura 6.15 – Stakeholders de Produto e Processo para Montagem e integração do UMB SCOE

Figura 6.16 – Stakeholders de Produto e Processo para Verificação do UMB SCOE

Figura 6.17 – Stakeholders de Produto e Processo para Transição do UMB SCOE

290

Figura 6.18 – Stakeholders de Produto e Processo para Operação durante Validação do UMB SCOE

Figura 6.19 – Stakeholders de Produto e Processo para Operação em AIT do UMB SCOE

Figura 6.20 – Stakeholders de Produto e Processo para Operação em Lançamento do UMB SCOE

291

Figura 6.21 – Stakeholders de Produto e Processo para Operação durante Aferição de Calibração do UMB SCOE

Figura 6.22 – Stakeholders de Produto e Processo para Operação -Manutenção do UMB SCOE

Figura 6.23 – Stakeholders de Produto e Processo para Transporte do UMB SCOE

292

Figura 6.24 – Stakeholders de Produto e Processo para Descomissionamento do UMB SCOE

6.5.2.2 Identificação dos Stakeholders de Organização do UMB SCOE

A identificação dos stakeholders de organização é feita em conjunto para todos os cenários dentro do esforço de desenvolvimento do UMB SCOE. Esse levantamento é feito por meio de diagramas DFD de contexto onde a organização desenvolvedora do UMB SCOE, é colocado no centro do diagrama, rodeados pelos stakeholders que são afetados ou tenham participação nos resultados da organização desenvolvedora, conforme mostra a Figura 6.25.

Figura 6.25 – Stakeholders de Organização do UMB SCOE

293

6.5.2.3 Stakeholders e suas preocupações

A partir do levantamento dos stakeholders e suas preocupações, toda essa informação é tabulada, organizada e classificada conforme preocupação de produto, processo e organização.

Preocupações de produto são geradas por stakeholders que são afetados

diretamente pelos atributos do produto e portanto serão os guias para a captura de requisitos de stakeholders para produto.

Da mesma forma, preocupações de processo serão os guias para a captura de requisitos de stakeholders para processos. A Tabela 6.2 lista todos os stakeholders e suas preocupações.

294

Tabela 6.2 – Visão Geral dos Stakeholders e suas Preocupações para Produto, Processo e Organização em Todos os Cenários do Ciclo de Vida

REQUISITOS DE STAKEHOLD

Tipo de

# Stakeholders stk Cenários do Ciclo de Vida Preocupação

1 SAT.DESV PRD U0: Desenvolvimento UMB SCOE Proteger o satélite, Funções vitais em AIT e lançamento. Confiabilidade X O 2 ESA/ISO/IEEE/ABNT PRD U0: Desenvolvimento UMB SCOE Normas: Requisitos aplicáveis. X C 3 SAT.LCH PRD U0: Desenvolvimento UMB SCOE Restrições técnicas e de segurança C 4 SAT.EGSE.Responsável PRD U0: Desenvolvimento UMB SCOE Funções e Interfaces atendidas; integração com EGSE. Prazo, Custo, Padronização. X I,O 5 SAT.AIT.GP PRD U0: Desenvolvimento UMB SCOE Processo e documentação O 6 SAT.SYS PRD U0: Desenvolvimento UMB SCOE Processos e Sistemas Padronizados X O 7 SAT.AIT PRD U0: Desenvolvimento UMB SCOE Segurança. Padronização e transportabilidade X O 8 UMB.DESV.Programador PRD U0: Desenvolvimento UMB SCOE Requisitos de software fechados M 9 UMB.DESV.GP PRD U0: Desenvolvimento UMB SCOE Processo de desenvolvimento O 10 UMB.DESV.Responsável PRD U0: Desenvolvimento UMB SCOE Requisitos Consolidados/Recursos/Prazo M 11 UMB.DESV.Realização PRD U0: Desenvolvimento UMB SCOE Realizável M 12 UMB.DESV.Financeiro PRD U0: Desenvolvimento UMB SCOE Estimativa de custo M

13 SAT.EGSE.Responsável PRD U11: Fabricação/Aquisição de componentes Prazo, Autorização. Padronização HW e SW. Qualidade X I,C 14 SAT.AIT.GP PRD U11: Fabricação/Aquisição de componentes Processos e Sistemas Padronizados X O 15 UMB.DESV.Programador PRD U11: Fabricação/Aquisição de componentes Codificação, Drivers dos equipamentos X M 16 UMB.DESV.Compras PRD U11: Fabricação/Aquisição de componentes Projeto e Caracteristicas fechadas; Pedidos; Prazo M 17 UMB.DESV.GP PRD U11: Fabricação/Aquisição de componentes Processo de Desenvolvimento,Acompanhamento Documentação M 18 UMB.DESV.Responsável PRD U11: Fabricação/Aquisição de componentes Requisitos fechados. Projeto autorizado. Interface com Cliente M 19 UMB.DESV.Realização PRD U11: Fabricação/Aquisição de componentes Desenhos, Preparar Procedimentos, Prazo M 20 UMB.DESV.Infraestrutura PRD U11: Fabricação/Aquisição de componentes Energia, espaço e ambiente. X

21 UMB.DESV.Almoxarifado PRD U11: Fabricação/Aquisição de componentes Materiais e Ferramentas M 22 UMB.DESV.Financeiro PRD U11: Fabricação/Aquisição de componentes Recursos Financeiros M 23 SAT.EGSE.Responsável PRD U12: Montagem e integração Prazo. Acompanhamento C,O 24 SAT.AIT.GP PRD U12: Montagem e integração Processo, documentação e acompanhamento. C 25 UMB.DESV.Programador PRD U12: Montagem e integração Integração do software c/ hardware M 26 UMB.DESV.Compras PRD U12: Montagem e integração Fazer e acompanhar pedidos e entrega M 27 UMB.DESV.GP PRD U12: Montagem e integração Acompanhamento Processos e Relatórios. M 28 UMB.DESV.Responsável PRD U12: Montagem e integração Integração dos componentes de acordo com projeto M 29 UMB.DESV.Realização PRD U12: Montagem e integração Realizar Montagem e Integração M 30 UMB.DESV.Infraestrutura PRD U12: Montagem e integração Energia, espaço, ambiente X

31 UMB.DESV.Almoxarifado PRD U12: Montagem e integração Fornecimento de Materiais e ferramentas I,M 32 SAT.EGSE.Responsável PRD U13: Verificação do UMB SCOE Matriz de Verificação completa e atendida. Aceitação M,O 33 SAT.AIT.GP PRD U13: Verificação do UMB SCOE Matriz de Verificação, TRR, TRB O 34 UMB.DESV.Programador PRD U13: Verificação do UMB SCOE Suporte M 35 UMB.DESV.GP PRD U13: Verificação do UMB SCOE Processo de Verificação, TRR, TRB. Entrega de docucmentação Documentação O 36 UMB.DESV.Responsável PRD U13: Verificação do UMB SCOE Requisitos Atendidos. Interface com Cliente M 37 UMB.DESV.Realização PRD U13: Verificação do UMB SCOE Realizar Verificação,Relatórios M 38 UMB.DESV.Infraestrutura PRD U13: Verificação do UMB SCOE Energia, espaço, ambiente. X

39 SAT.AIT.Infraestrutura PRD U2: Transiçãp UMB SCOE Energia, espaço, ambiente. X

40 SAT.EGSE.Responsável PRD U2: Transiçãp UMB SCOE Verificação Requisitos, Pacote de dados. I,O 41 SAT.AIT.GP PRD U2: Transiçãp UMB SCOE DRB O 42 UMB.DESV.Financeiro PRD U2: Transiçãp UMB SCOE Receber M 43 UMB.DESV.GP PRD U2: Transiçãp UMB SCOE DRB. Aceitação M 44 UMB.DESV.Responsável PRD U2: Transiçãp UMB SCOE Requisitos atendido.Relatórios M 45 UMB.DESV.Realização PRD U2: Transiçãp UMB SCOE Suporte técnico. Transporte. M 46 UMB.DESV.Almoxarifado PRD U2: Transiçãp UMB SCOE Sobressalentes, Container, Material de Embalagem. I 47 OCOE.Responsável PRD U31: Operação durante Validação do UMB SCInterface remota e automatizada. Execução e validação de scripts X

48 SAT.AIT.Infraestrutura PRD U31: Operação durante Validação do UMB SCEnergia, espaço, ambiente. X

49 SAT.EGSE.Responsável PRD U31: Operação durante Validação do UMB SCValidação de interfaces e funcionalidade automática. Self-test. O 50 SAT.AIT.GP PRD U31: Operação durante Validação do UMB SCTRR O 51 UMB.Operador PRD U31: Operação durante Validação do UMB SCConexões e Setup. Self-test. Modo de operação manual e Local X M 52 SAT.AIT.CondutorTeste PRD U31: Operação durante Validação do UMB SCVerificação e histórico das interfaces X O 53 SAT.AIT PRD U32: Operação em AIT do UMB SCOE Eqp Seguro, não perturba ambiente e alerta q satélite esta ligado/RF, Pradronizado X M,O 54 OCOE.Responsável PRD U32: Operação em AIT do UMB SCOE Excução Scripts. Inteface remota e automática X

55 SAT.AIT.Infraestrutura PRD U32: Operação em AIT do UMB SCOE Energia, espaço, ambiente. X 56 SAT.EGSE.Responsável PRD U32: Operação em AIT do UMB SCOE Validação com o EGSE. Transportabilidade Interna X

57 SAT.AIT.GP PRD U32: Operação em AIT do UMB SCOE Garantir q não põe em risco o satélite X C 58 UMB.Operador PRD U32: Operação em AIT do UMB SCOE Interface usuário intuitiva; Pouca operação local. Salvar e Carregar configuração. X

59 SAT.AIT.CondutorTeste PRD U32: Operação em AIT do UMB SCOE Interface remota, automatismo, selftest. X C 60 SAT.SYS PRD U32: Operação em AIT do UMB SCOE Única interface elétrica com EGSE. Sinais vitais: Energia, Monitoração, Controle X

61 OCOE.Responsável PRD U33: Operação em Lançamento do UMB SCOEOperações unicamente remotas X 62 SAT.EGSE.Responsável PRD U33: Operação em Lançamento do UMB SCOETransportabilidade. Alimentar o satélite X 63 SAT.AIT.GP PRD U33: Operação em Lançamento do UMB SCOEGarantir q não põe em risco o lançamento X 64 UMB.Operador PRD U33: Operação em Lançamento do UMB SCOEPouca interação local (on/off) X

65 SAT.AIT.CondutorTeste PRD U33: Operação em Lançamento do UMB SCOEInterface remota. Confiabilidade. Funcionar sem interrupção: confiabilidade X C 66 SAT.DESV PRD U33: Operação em Lançamento do UMB SCOESinais Vitais, Bateria Carregada/Monitorada X

67 SAT.LCH PRD U33: Operação em Lançamento do UMB SCOERequisitos de segurança, transporte e operação. Aterramento X 68 SAT.LCH.Infraestrutura PRD U33: Operação em Lançamento do UMB SCOEEnergia, espaço, ambiente. X 69 SAT.AIT.Infraestrutura PRD U34: Operação durante Aferição de Calibraçã Energia, espaço, ambiente. X 70 SAT.EGSE.Responsável PRD U34: Operação durante Aferição de Calibraçã Sem desmontar ou remover os equipamentos, Prazo, Facilidade X

71 SAT.AIT.GP PRD U34: Operação durante Aferição de Calibraçã Processo, Certificação, Relatório O 72 UMB.Operador PRD U34: Operação durante Aferição de Calibraçã Suporte X M 73 CALIBRAÇÃO PRD U34: Operação durante Aferição de Calibraçã Processo padronizado e Automatizado X M 74 CALIBRAÇÃO.Responsável PRD U34: Operação durante Aferição de Calibraçã Interfaces curtas e acessíveis, Interface usuário c/ função de calibração, Procedimento, relatório X

75 SAT.EGSE.Almoxarifado PRD U35: Operação – Manutenção do UMB SCOE Política de sobressalentes: Disponibilidade e Reposição. X M 76 SAT.AIT.Infraestrutura PRD U35: Operação – Manutenção do UMB SCOE Energia, espaço, ambiente. X

77 SAT.EGSE.Responsável PRD U35: Operação – Manutenção do UMB SCOE Prazo, Manutenção baseada em Sobressalentes. Validação X M 78 SAT.AIT.GP PRD U35: Operação – Manutenção do UMB SCOE NC. Causa da falha. Relatório M 79 UMB.Operador PRD U35: Operação – Manutenção do UMB SCOE Manual de Manutenção. Pontos de testes M,O 80 UMB.DESV.Compras PRD U35: Operação – Manutenção do UMB SCOE Prazo M 81 UMB.DESV.GP PRD U35: Operação – Manutenção do UMB SCOE NC. Processo M 82 UMB.DESV.Responsável PRD U35: Operação – Manutenção do UMB SCOE Sobressalentes Necessários, Suporte na Análise X I 83 UMB.DESV.Financeiro PRD U35: Operação – Manutenção do UMB SCOE Orçamento p/ reposição de sobressalentes O 84 UMB.DESV.Realização PRD U35: Operação – Manutenção do UMB SCOE Avaliação do componente danificado. M 85 SAT.EGSE.Almoxarifado PRD U36: Transporte do UMB SCOE Armazenagem de containers X M 86 SAT.AIT PRD U36: Transporte do UMB SCOE Baixo custo e pouc necessidade de pessoal. Containers padronizados e reutilizáveis. X M 87 SAT.EGSE.Responsável PRD U36: Transporte do UMB SCOE Equipamentos protegidos contra impacto e ambiente. X

88 UMB.Operador PRD U36: Transporte do UMB SCOE Rápido e fácil X 89 Transporte Aéreo PRD U36: Transporte do UMB SCOE Dimensões padronizada. Materiais permitidos. Despressurização X 90 Transporte Terrestre PRD U36: Transporte do UMB SCOE Condições climáticas. Vibração, Impacto X 91 Transportadora PRD U36: Transporte do UMB SCOE Peso, Centro de massa. Paletização X

92 SAT.DESV PRD U4: Descomissionamento UMB SCOE Fim do programa C 93 SAT.AIT PRD U4: Descomissionamento UMB SCOE Reciclagem em outros programas O 94 SAT.EGSE.Responsável PRD U4: Descomissionamento UMB SCOE Segurança da informação O 95 SAT.AIT.GP PRD U4: Descomissionamento UMB SCOE NC, NRB M 96 Coleta de Lixo PRD U4: Descomissionamento UMB SCOE Coleta de materiais O 97 Agências Ambientais PRD U4: Descomissionamento UMB SCOE Materiais não poluentes X C

98 Agências Ambientais ORG U0: Desenvolvimento UMB SCOE Poluentes C X 99 MT ORG U0: Desenvolvimento UMB SCOE Normas de trabalho e segurança C X 100 Governo ORG U0: Desenvolvimento UMB SCOE Imposto. Desenvolvimento industrial C X 101 CREA ORG U0: Desenvolvimento UMB SCOE Registros profissionais C X 102 Fornecedores de Componen ORG U0: Desenvolvimento UMB SCOE Componentes/Requisitos; Parcerias I X 103 Fornecedores de Serviços ORG U0: Desenvolvimento UMB SCOE Serviços externos/Requisitos; Parcerias I,M X 104 Mercado ORG U0: Desenvolvimento UMB SCOE Oportunidades de negócios X 105 Coleta de Lixo ORG U0: Desenvolvimento UMB SCOE Coleta de materiais X 106 Junta comercial ORG U0: Desenvolvimento UMB SCOE Regulamentação X 107 Competidores ORG U0: Desenvolvimento UMB SCOE Benchmark X 108 Cliente ORG U0: Desenvolvimento UMB SCOE Satisfação/Insatisfação, Contratos X 109 Agências de Fomento ORG U0: Desenvolvimento UMB SCOE Conteúdo nacional / Recursos financeiros X 110 Agência Espacial ORG U0: Desenvolvimento UMB SCOE Demanda espacial X 111 Sindicato ORG U0: Desenvolvimento UMB SCOE Salários e Condições X

295

6.5.2.4 Requisitos de Stakeholders

A partir da identificação e classificação das preocupações dos stakeholders é possível identificar Requisitos de Stakeholders para produto, processo e organização por meio do método de matrizes funcional de qualidade QFD, onde as fontes de “o que” é importante para os stakeholders são mapeadas para as colunas de “como” elas se traduzem para os requisito dos stakeholders.

Identificar e listar requisitos de stakeholders é uma maneira de agrupar preocupações semelhantes que mapeiam para os mesmos requisitos. Dessa forma é possível agrupar requisitos e eliminar repetições.

6.5.2.4.1 Requisitos de Stakeholder para Produto

A Tabela 6.3 mostra a matriz QFD dos Requisitos de Stakeholders para

produto (colunas em azul) derivados das preocupações dos stakeholders para cada cenário do ciclo de vida.

Note que muitas das preocupações dos stakeholders para produto não podem ser unicamente mapeadas para requisitos do produto pois são afetadas também por atributos dos processos do ciclo de vida. Essas preocupações estão indicados com “PP_” na coluna “Alocação das Preocupações” da Tabela 6.3. Os requisitos de stakeholders para os processos são tratados na Seção 6.5.2.4.2.

296

Tabela 6.3 – Matriz de Requisitos de Produto derivados das preocupação dos Stakeholders

Requisitos dos stakeholders para Produto:

Proteção das interfaces elétricas do satélite · Simulador de interfaces do satélite
Alimentar o satélite
AD05: Descrição Interfaces do Satélite · Monitorar sinais presentes no umbilical · Comandos básicos no satélite
Carregar bateria
Centralizar conexões ao satélite. · RD03: Manual do lançador
AD01: Especificação do EGSE
AD02: Protocolo de comunicação do EGSE · AD03: Requisitos de software para EGSE
AD04: Especificação de container de operação e transporte do EGSE · RD01: ISO 14625: Requisitos Gerais de GSE
Parâmetros configurável por arquivo
Alimentação de entrada: Tensão, frequência da rede. Consumo máxim · Circuitos imune a falhas. Confiabilidade
Função nobreak interno · Dimensões máximas
Temperatura de trabalho

297

Identificação e cores
Requisitos de perturbação ao ambiente: Ruído máximo, Vibração, Quantidade de calor emitida.
Interferência eletromagnética
Lista de sobressalentes: (todos os componentes do UMB SCOE) · RD02:ISO14620-1:Requisitos de segurança
Requisito de aterramento
Função de identificação que o satélite esta ligado e irradiando · Automatismo
Interface de especial para calibração · Função modo calibração
Materiais não poluentes · Selftest
Utilizar o mesmo rack para operação e transporte · Tempo de vida do UMB SCOE

6.5.2.4.2 Requisitos de Stakeholder para Processo

Da mesma forma como os requisitos de stakeholders para produto, a partir da classificação dos stakeholders e suas preocupações, é possível listar atributos do processo que são percebidos pelos stakeholders. Os stakeholders de processo são aqueles que são fontes/destino de entradas, saídas, controles ou mecanismos dos processos do ciclo de vida.

A Tabela 6.4 mapeia os requisitos para processo (colunas em roxo claro) com os stakeholders.

298

Tabela 6.4 – Matriz de Requisitos de Stakeholders para Processos

1 SAT.DESV PRD U0: Desenvolvimento UMB SCOE Proteger o satélite, Funções vitais em AIT e lançamento. Confiabilidade 2 ESA/ISO/IEEE/ABNT PRD U0: Desenvolvimento UMB SCOE Normas: Requisitos aplicáveis.

3 SAT.LCH PRD U0: Desenvolvimento UMB SCOE Restrições técnicas e de segurança

4 SAT.EGSE.Responsável PRD U0: Desenvolvimento UMB SCOE Funções e Interfaces atendidas; integração com EGSE. Prazo, Custo, Padronização. 5 SAT.AIT.GP PRD U0: Desenvolvimento UMB SCOE Processo e documentação

6 SAT.SYS PRD U0: Desenvolvimento UMB SCOE Processos e Sistemas Padronizados

7 SAT.AIT PRD U0: Desenvolvimento UMB SCOE Segurança. Padronização e transportabilidade 8 UMB.DESV.Programador PRD U0: Desenvolvimento UMB SCOE Requisitos de software fechados

9 UMB.DESV.GP PRD U0: Desenvolvimento UMB SCOE Processo de desenvolvimento

10 UMB.DESV.Responsável PRD U0: Desenvolvimento UMB SCOE Requisitos Consolidados/Recursos/Prazo 11 UMB.DESV.Realização PRD U0: Desenvolvimento UMB SCOE Realizável

12 UMB.DESV.Financeiro PRD U0: Desenvolvimento UMB SCOE Estimativa de custo

13 SAT.EGSE.Responsável PRD U11: Fabricação/Aquisição de componentes Prazo, Autorização. Padronização HW e SW. Qualidade 14 SAT.AIT.GP PRD U11: Fabricação/Aquisição de componentes Processos e Sistemas Padronizados

15 UMB.DESV.Programador PRD U11: Fabricação/Aquisição de componentes Codificação, Drivers dos equipamentos

16 UMB.DESV.Compras PRD U11: Fabricação/Aquisição de componentes Projeto e Caracteristicas fechadas; Pedidos; Prazo

17 UMB.DESV.GP PRD U11: Fabricação/Aquisição de componentes Processo de Desenvolvimento,Acompanhamento Documentação 18 UMB.DESV.Responsável PRD U11: Fabricação/Aquisição de componentes Requisitos fechados. Projeto autorizado. Interface com Cliente 19 UMB.DESV.Realização PRD U11: Fabricação/Aquisição de componentes Desenhos, Preparar Procedimentos, Prazo

21 UMB.DESV.Almoxarifado PRD U11: Fabricação/Aquisição de componentes Materiais e Ferramentas 22 UMB.DESV.Financeiro PRD U11: Fabricação/Aquisição de componentes Recursos Financeiros

23 SAT.EGSE.Responsável PRD U12: Montagem e integração Prazo. Acompanhamento

24 SAT.AIT.GP PRD U12: Montagem e integração Processo, documentação e acompanhamento. 25 UMB.DESV.Programador PRD U12: Montagem e integração Integração do software c/ hardware

26 UMB.DESV.Compras PRD U12: Montagem e integração Fazer e acompanhar pedidos e entrega 27 UMB.DESV.GP PRD U12: Montagem e integração Acompanhamento Processos e Relatórios.

28 UMB.DESV.Responsável PRD U12: Montagem e integração Integração dos componentes de acordo com projeto 29 UMB.DESV.Realização PRD U12: Montagem e integração Realizar Montagem e Integração

31 UMB.DESV.Almoxarifado PRD U12: Montagem e integração Fornecimento de Materiais e ferramentas

32 SAT.EGSE.Responsável PRD U13: Verificação do UMB SCOE Matriz de Verificação completa e atendida. Aceitação 33 SAT.AIT.GP PRD U13: Verificação do UMB SCOE Matriz de Verificação, TRR, TRB

34 UMB.DESV.Programador PRD U13: Verificação do UMB SCOE Suporte

35 UMB.DESV.GP PRD U13: Verificação do UMB SCOE Processo de Verificação, TRR, TRB. Entrega de docucmentação Documentação 36 UMB.DESV.Responsável PRD U13: Verificação do UMB SCOE Requisitos Atendidos. Interface com Cliente

37 UMB.DESV.Realização PRD U13: Verificação do UMB SCOE Realizar Verificação,Relatórios

40 SAT.EGSE.Responsável PRD U2: Transiçãp UMB SCOE Verificação Requisitos, Pacote de dados. 41 SAT.AIT.GP PRD U2: Transiçãp UMB SCOE DRB

42 UMB.DESV.Financeiro PRD U2: Transiçãp UMB SCOE Receber

43 UMB.DESV.GP PRD U2: Transiçãp UMB SCOE DRB. Aceitação

44 UMB.DESV.Responsável PRD U2: Transiçãp UMB SCOE Requisitos atendido.Relatórios 45 UMB.DESV.Realização PRD U2: Transiçãp UMB SCOE Suporte técnico. Transporte.

46 UMB.DESV.Almoxarifado PRD U2: Transiçãp UMB SCOE Sobressalentes, Container, Material de Embalagem.

49 SAT.EGSE.Responsável PRD U31: Operação durante Validação do UMB SCValidação de interfaces e funcionalidade automática. Self-test. 50 SAT.AIT.GP PRD U31: Operação durante Validação do UMB SCTRR

51 UMB.Operador PRD U31: Operação durante Validação do UMB SCConexões e Setup. Self-test. Modo de operação manual e Local 52 SAT.AIT.CondutorTeste PRD U31: Operação durante Validação do UMB SCVerificação e histórico das interfaces

53 SAT.AIT PRD U32: Operação em AIT do UMB SCOE Eqp Seguro, não perturba ambiente e alerta q satélite esta ligado/RF, Pradronizado 57 SAT.AIT.GP PRD U32: Operação em AIT do UMB SCOE Garantir q não põe em risco o satélite

59 SAT.AIT.CondutorTeste PRD U32: Operação em AIT do UMB SCOE Interface remota, automatismo, selftest.

65 SAT.AIT.CondutorTeste PRD U33: Operação em Lançamento do UMB SCOEInterface remota. Confiabilidade. Funcionar sem interrupção: confiabilidade 71 SAT.AIT.GP PRD U34: Operação durante Aferição de Calibraçã Processo, Certificação, Relatório

72 UMB.Operador PRD U34: Operação durante Aferição de Calibraçã Suporte

73 CALIBRAÇÃO PRD U34: Operação durante Aferição de Calibraçã Processo padronizado e Automatizado

75 SAT.EGSE.Almoxarifado PRD U35: Operação – Manutenção do UMB SCOE Política de sobressalentes: Disponibilidade e Reposição. 77 SAT.EGSE.Responsável PRD U35: Operação – Manutenção do UMB SCOE Prazo, Manutenção baseada em Sobressalentes. Validação 78 SAT.AIT.GP PRD U35: Operação – Manutenção do UMB SCOE NC. Causa da falha. Relatório

79 UMB.Operador PRD U35: Operação – Manutenção do UMB SCOE Manual de Manutenção. Pontos de testes 80 UMB.DESV.Compras PRD U35: Operação – Manutenção do UMB SCOE Prazo

81 UMB.DESV.GP PRD U35: Operação – Manutenção do UMB SCOE NC. Processo

82 UMB.DESV.Responsável PRD U35: Operação – Manutenção do UMB SCOE Sobressalentes Necessários, Suporte na Análise 83 UMB.DESV.Financeiro PRD U35: Operação – Manutenção do UMB SCOE Orçamento p/ reposição de sobressalentes

84 UMB.DESV.Realização PRD U35: Operação – Manutenção do UMB SCOE Avaliação do componente danificado. 85 SAT.EGSE.Almoxarifado PRD U36: Transporte do UMB SCOE Armazenagem de containers

86 SAT.AIT PRD U36: Transporte do UMB SCOE Padronização de containers. Baixo custo. Reduzir necessidade de pessoal. 92 SAT.DESV PRD U4: Descomissionamento UMB SCOE Fim do programa

93 SAT.AIT PRD U4: Descomissionamento UMB SCOE Reciclagem em outros programas 94 SAT.EGSE.Responsável PRD U4: Descomissionamento UMB SCOE Segurança da informação

95 SAT.AIT.GP PRD U4: Descomissionamento UMB SCOE NC, NRB

96 Coleta de Lixo PRD U4: Descomissionamento UMB SCOE Coleta de materiais

97 Agências Ambientais PRD U4: Descomissionamento UMB SCOE Materiais não poluentes 98 Agências Ambientais ORG U0: Desenvolvimento UMB SCOE Poluentes

99 MT ORG U0: Desenvolvimento UMB SCOE Normas de trabalho e segurança

100 Governo ORG U0: Desenvolvimento UMB SCOE Imposto. Desenvolvimento industrial 101 CREA ORG U0: Desenvolvimento UMB SCOE Registros profissionais

102 Fornecedores de Componen ORG U0: Desenvolvimento UMB SCOE Componentes/Requisitos; Parcerias 103 Fornecedores de Serviços ORG U0: Desenvolvimento UMB SCOE Serviços externos/Requisitos; Parcerias

X O PP_ x X C PP_ x x

C _P_ x

X I,O PP_ x x x x x x x x O _P_ x x x x

X O PP_ x x x x x x x x x x X O PP_ x x x x

M _P_ x x

O _P_ x x x x M _P_ x x x x x x M _P_ x M _P_ x

X I,C PP_ x x x x x x X O PP_ x x

M _P_ x x x x

M _P_ x x x M _P_ x x

M _P_ x

M _P_ x x x M _P_ x

M _P_ x

C,O _P_ x x x x x C _P_ x x x x x M _P_ x

M PP_ x x x M _P_ x x x x x M _P_ x

M _P_ x I,M _P_ x

M,O _P_ x x x x x O _P_ x x x M _P_ x O _P_ x x x M _P_ x x x M _P_ x x x

I,O _P_ x x x

O _P_ x x x x M _P_ x M _P_ x M _P_ x x x x

M _P_ x I _P_ x

O _P_ x x x x O _P_ x x x

X M PP_ x x X O PP_ x x

X M,O PP_ x x x x X C PP_ x

X C PP_ x X C PP_ x O _P_ x x

X M PP_ x X M PP_ x x

X M PP_ x x

X M PP_ x x x x M _P_ x

M,O _P_ x x

M _P_ x x x M _P_ x

X I PP_ x x O _P_ x x x

M _P_ x

X M PP_ x X M PP_ x

C _P_ x O _P_ x O _P_ x x M _P_ x O _P_ x

X C PP_ x x x C X _PO x x x x C X _PO x x x x x x x x

C X _PO x x x C X _PO x

I X _PO x x x x I,M X _PO x x x

6.5.2.4.3 Requisitos de Stakeholders para Organização

A partir da identificação e classificação dos stakeholders e suas preocupações, é possível listar atributos da organização desenvolvedora que são percebidos pelos stakeholders. Os stakeholders de organização são aqueles externos à organização mas que de alguma forma são afetados pela forma como a organização desenvolvedora atua.

A Tabela 6.5 mapeia as preocupações dos stakeholders para requisitos da organização (colunas em verde-claro).

299

Tabela 6.5 – Matriz de Requisitos de Organização

REQUISITOS DE STAKEHOLDER –> REQUISITO PARA ORGANIZAÇÃO

Tipo de

# Stakeholders stk Cenários do Ciclo de Vida Preocupação

98 Agências Ambientais ORG U0: Desenvolvimento UMB SCOE 99 MT ORG U0: Desenvolvimento UMB SCOE 100 Governo ORG U0: Desenvolvimento UMB SCOE 101 CREA ORG U0: Desenvolvimento UMB SCOE 102 Fornecedores de Componen ORG U0: Desenvolvimento UMB SCOE 103 Fornecedores de Serviços ORG U0: Desenvolvimento UMB SCOE 104 Mercado ORG U0: Desenvolvimento UMB SCOE 105 Coleta de Lixo ORG U0: Desenvolvimento UMB SCOE 106 Junta comercial ORG U0: Desenvolvimento UMB SCOE 107 Competidores ORG U0: Desenvolvimento UMB SCOE 108 Agências de Fomento ORG U0: Desenvolvimento UMB SCOE 109 Agência Espacial ORG U0: Desenvolvimento UMB SCOE 110 Sindicato ORG U0: Desenvolvimento UMB SCOE

Poluentes

Normas de trabalho e segurança Imposto. Desenvolvimento industrial Registros profissionais Componentes/Requisitos; Parcerias Serviços externos/Requisitos; Parcerias Oportunidades de negócios

Coleta de materiais Regulamentação Benchmark

Conteúdo nacional / Recursos financeiros Demanda de satélites

Salários e Condições

C X _PO x

C X _PO x x x x

C X _PO x x x C X _PO x

I X _PO x x x I,M X _PO x x x X __O x

X __O x

X __O x x X __O x

X __O x x

6.5.2.5 Medidas de Efetividade – MOE

Para medir a satisfação do stakeholders são levantadas as Medidas de Efetividades – MoE para os requisitos de stakeholder utilizando as matrizes QFD conforme pode ser observado na Tabela 6.6. Note que um requisito de stakeholder pode mapear mais do que uma MOE e vice-versa, justificando assim a utilização da matriz requisito versus MOE. Medidas de Efetividade podem ser decompostas em outras MOE e em Medidas de Performance – MOP até que sejam possíveis de serem verificadas.

300

Tabela 6.6 – Matriz QFD das Medidas de Efetividade MoE e Interesse dos Stakeholders para Produto

301

Tabela 6.7 – Classificação das Medidas de Efetividade – MoE de Produto

MOE_002 Monitorar Sinais Monitorar sinais vitais do satélite presentes no conector umbilical BF M MOE_002.1 Prover monitoração por range (máximo, mínimo) configurável F M MOE_002.2 Disparar eventos em função de cruzamento de range F M MOE_002.3 Tempo de resposta após cruzamento de range de 20ms a 1000ms configurável P M MOE_002.4 Tipos de sinais de monitoração: tensão, resistência e contador de pulsos F M

MOE_004 Executar ações Executar eventos automaticamente decorrente de monitoração ou manualmente via interface local ou remota. BF M MOE_004.1 Eventos configuráveis: lista com: identificação, descrição, abilitação e sequencia F M MOE_005 Modos de Operação O UMB SCOE deve operar remotamente e simultaneamente ao modo Local. BF M MOE_005.1 O modo de operação local deve ter prioridade ao modo de operação remoto. F M MOE_005.2 O mode de operação local deve ser protegido por senha. F D MOE_005.3 O modo de operação remoto deve possuir acesso, controle e monitoração equivalente ao mode de operação local. F M MOE_006 Auxiliar Calibração Função interna de auxílio a calibração. BF D MOE_006.1 Modo calibração protegido por senha. F D MOE_006.2 Interface elétrica de fácil acesso. I D MOE_007 Alimentar Satélite Prover alimentação para o satélite durante as atividades de AIT e lançamento BF M MOE_007.1 Alimentar o satélite com potência suficiente para executar todas operações do satélite F M MOE_007.2 Ser capaz de carregar a bateria do satélite F M MOE_007.3 Compensar a perda de tensão causada pelo cabo umbilical de 70 metros F M MOE_007.4 Proteger o satélite contra sobretensão F M MOE_008 Interfacear com o EGSE Prover interface com os demais elementos do EGSE: OCOE, SAS e TTC SCOE em acordo com AD01 I M MOE_009 Self-Test O UMB SCOE deve ser capaz de executar Self-teste completo de interface e funções F M MOE_010 Simular Funcinamento O UMB SCOE deve possuir modo simulação de software para teste de interface remota e validação de BF M

MOE_011 Proteger eqp durante opeO container deve fornce suporte e proteger os elementos internos contra impacto, vibração, poeira e humidade de BF M

MOE_011.1 O UMB SCOE deve ser prático para transporte sem a necessidade de sua desmontagem. P D MOE_011.2 O UMB SCOE deve ser compácto e fácil de movimentação interna. P D MOE_011.3 Deve utilizar containers padrão ao EGSE de acordo com AD04 D M MOE_012 Não perturbar ambiente O UMB SCOE deve minimizar a emissão de ruido sonoro, vibração de acordo com AD01 e RD03 I D MOE_013 Automatizar tarefas O UMB SCOE deve permitir automatizar tarefas. BF D MOE_013.1 Deve ser possível gerar, gravar, executar sequencias de eventos. F M MOE_013.2 O UMB SCOE deve inicializar automaticamente em condição conhecida e que não comprometa o satélite F M MOE_014 Tempo de vida O UMB SCOE deve ter vida útil >= 10 anos P D MOE_015 Alimentação O UMB SCOE deve ser alimentado de acordo com AD01 e RD03 I M MOE_016 Segurança O UMB SCOE deve atender requisitos de segurança de acordo c RD02 D M MOE_017 Proteger Satélite O UMB SCOE deve minimizar a probabilidade de falha e reduzir a gravidade dos efeitos de falha no satélite e nos BF M

MOE_017.1 Circuito de proteção independente da função principal e independente para cada tipo de interface/sinal. F D MOE_017.2 Os circuitos de proteção devem atuar em caso de deteção de falha em até 20 ms. P M

No caso de detecção de falha, o UMB SCOE deve alarmar localmente e remotamente e manter as demais funções

operacionais. F M Em caso de pane no software ou no computador e houver o reinício do software, o UMB SCOE deve inicializar em modo

seguro ao satélite, evitando a interrupção de funções vitais ao satélite. F M MOE_018 Alarmar Gerar e registrar alarme em caso de evento notório BF M MOE_018.1 Tipos de eventos: Alarme audível, alarme luminoso, mensagem remota I M MOE_018.2 Alarme luminoso do estado ligado/desligado do satélite F M MOE_018.3 Alarme luminoso do estado de irradiação RF do satélite/EGSE F M MOE_019 Rotear Rotear sinais ao EGSE BF M MOE_019.1 Interfacear com SAS SCOE (linhas dedicadas de potência) I M MOE_019.2 Interfacear com OCOE (TMTC – LAN) I M MOE_019.3 Interfacer com TTC SCOE (TMTC – RS-422) I M

6.5.3 Análise de Requisitos do UMB SCOE – GS3

O processo de Análise de Stakeholder aplicado ao UMB SCOE segue o

processo descrito na A.4.

302

Dos Requisitos de Stakeholders e das MOEs são identificados os pressupostos considerados durante o levantamento.

Para manter o histórico e evolução dos requisitos, os pressupostos identificados serão arquivados juntamente com os requisitos de sistema.

Os pressupostos podem gerar requisitos de restrições para as interfaces e para os sistemas que fazem interface com o UMB SCOE. Como exemplo a MOE_007 “Prover alimentação para o satélite durante as atividades de AIT e lançamento” gera o pressuposto 15:

O subsistema PSS do satélite deve possuir entrada diretamente conectada no barramento do satélite

Tabela 6.8 – MOEs e seus Pressupostos

MOE_ID TYPE MOE / MOP Descrição das Medidas de Efetividade do UMB SCOE Pressupostos

MOE_001 MOE_001.1 MOE_001.2 MOE_001.3 MOE_001.4 MOE_001.5 MOE_002 MOE_002.1 MOE_002.2 MOE_002.3 MOE_002.4 MOE_003 MOE_003.1 MOE_004

MOE_004.1

MOE_004.2 MOE_005 MOE_005.1 MOE_005.2 MOE_005.3 MOE_006 MOE_006.1 MOE_006.2 MOE_007 MOE_007.1 MOE_007.2 MOE_007.3 MOE_007.4 MOE_008 MOE_009

MOE_010

MOE_011

MOE_011.1

MOE_011.2 MOE_011.3 MOE_012 MOE_013 MOE_013.1 MOE_013.2 MOE_014 MOE_015 MOE_016

MOE_017

MOE_017.1 MOE_017.2

MOE_017.3

MOE_017.4

MOE Interface única com o satelite UMB SCOE deve ser capaz de tratar todos sinais presentes no conector umbilical/separação. I M Press_01 O conector umbilical do satélite terá sinais considerados essenciais e necessários para … MOE Saída de alimentação para o satélite . I M Press_02 O satélite possuir uma entrada de alimentação direta no barramento e protegida por u… MOE Saídas para envio de pulso de comando I M Press_03 Pulso de comando para alterar estado de relés liga/desliga de equipamentos que não … MOE Entradas de monitoração protegidas de curto e sobretensão e com impendância maior que 10MOhms I M Press_04 Os sinais vitais disponíveis no umbilical com impedância de <=100KOhm.

MOE Entrada TM serial RS422 de protegida de curto de acordo com AD001 I M Press_05 Sinal de” vídeo” de telemetria derivado da saída do OBC sem modulação de RF.

MOE Saída de TC serial RS422 protegida de sobretensão e curto de acordo com AD001 I M Press_06 Sinal de “vÍdeo”de telecomando diretamente na entrado do OBC sem modulação de RF… MOE Monitoração Monitorar sinais vitais do satélite presentes no conector umbilical F M Press_07 Sinais vitais presentes no umbilical que indiquem o funcionamento do barramento e es… MOE Monitoração Prover monitoração por range (máximo, mínimo) configurável F M Press_08 Monitorar os sinais essenciais para tomada de decisão baseado em valores limites.

MOE Monitoração Disparar eventos em função de cruzamento de range F M Press_08

MOP Monitoração Tempo de resposta após cruzamento de range de 20ms a 1000ms configurável P M Press_09 Detecção e minimização de anomalia com efeito catastrófico e para eventos programá… MOE Monitoração Tipos de sinais de monitoração: tensão, resistência e contador de pulsos F M

MOE Comandos por fio ao Satélite Gerar comando por fio para ligar/desligar equipamentos essenciais durante AIT. Ex.: Bateria. F M Press_03 MOE Comandos por fio ao Satélite Simular sinais de separação, abertura de painel solar etc. F M

MOE Eventos Automático Executar eventos automaticamente decorrente de monitoração ou manualmente via interface local ou remota. F M Press_07 MOE Eventos Automático Tipos de eventos: Alarme audível, alarme luminoso, mensagem remota, Comando por fio ao satélite e Comando I M

MOE Eventos Automático Eventos configuráveis: lista com: identificação, descrição, abilitação e sequencia F M

MOE Modos de Operação O UMB SCOE deve operar através de dois modos de operação simultaneamente: Local e Remoto. F M Press_10 Minimizar ao máximo a intervenção local no UMB SCOE. Exceto conectar e ligar o UMB… MOE Modos de Operação O modo de operação local deve ter prioridade ao modo de operação remoto. F M Press_11 A prioridade local deve ser maior que a remota para o caso de falha do link de comunic… MOE Modos de Operação O mode de operação local deve ser protegido por senha. F D Press_12 A proteção por senha para evitar operação local por pessoas desabilitadas … MOE Modos de Operação O modo de operação remoto deve possuir acesso, controle e monitoração equivalente ao mode de operação local. F M Press_10 … MOE Calibração Função interna de auxílio a calibração. F D Press_13 Facilitar a aferição de calibração dos equipamentos para evitar que o UMB SCOE seja d… MOE Calibração Modo calibração protegido por senha. F D Press_14 Evitar que o UMB SCOE entre em modo calibração durante operação normal e compro… MOE Calibração Interface elétrica de fácil acesso. I D Press_13 … MOE Alimentação Prover alimentação para o satélite durante as atividades de AIT e lançamento F M Press_15 Facilitar a movimentação do satélite sem a necessidade de utilizar o SAS SCOE em toda… MOE Alimentação Alimentar o satélite com potência suficiente para executar todas operações do satélite F M Press_15 … MOE Alimentação Ser capaz de carregar a bateria do satélite F M Press_15 … MOE Alimentação Compensar a perda de tensão causada pelo cabo umbilical de 70 metros F M Press_16 Distância elétrica assumida entre o satélite e o UMB SCOE durante lançamento. … MOE Alimentação Proteger o satélite contra sobretensão F M Press_17 Alimentação conectada diretamente no barramento deve ser protegido de sobretensã … MOE Interface com o EGSE Prover interface com os demais elementos do EGSE: OCOE, SAS e TTC SCOE em acordo com AD01 I M … MOE Self-Test O UMB SCOE deve ser capaz de executar Self-teste completo de interface e funções F M Press_18 Para self-test de interface, será necessário um simulador de interface do satélite. … MOE Simulação O UMB SCOE deve possuir modo simulação de software para teste de interface remota e validação de procedimentos F M Press_19 No modo simulação o software do UMB SCOE responde remotamente simulando que a…

MOE Transportabilidade e dimensões O UMB SCOE deve ser prático para transporte sem a necessidade de sua desmontagem. P D Press_20 O UMB SCOE deve utilizar padrão de rack-container do EGSE, onde o rack possui tampa… MOE Transportabilidade e dimensões O container deve proteger os equipamentos e elementos contra impacto, vibração, poeira e humidade de acordo com F M Press_20

MOE Transportabilidade e dimensões O UMB SCOE deve ser compácto e fácil de movimentação interna. P D Press_20 MOE Transportabilidade e dimensões Deve utilizar containers padrão ao EGSE de acordo com AD04 D M Press_20

MOE Não perturbar ambiente O UMB SCOE deve minimizar a emissão de ruido sonoro, vibração de acordo com AD01 e RD03 F D Press_21 O UMB SCOE deve ficar ao lado do satélite durante o AIT, por isso deve respeitar restri … MOE Automatismo O UMB SCOE deve permitir automatizar tarefas. F D Press_22 Tarefas repetitivas devem ser automatizadas localmente. Ex. : monitoração, self-test, s… MOE Automatismo Deve ser possível gerar, gravar, executar sequencias de eventos. F M Press_23 Sequencias de eventos são geradas conforme necessidade e não devem fazer parte do… MOE Automatismo O UMB SCOE deve inicializar automaticamente em condição conhecida e que não comprometa o satélite F M Press_24 Em caso de falha do computador ou falha de alimentação, o UMB SCOE deve retornar … MOE Tempo de vida O UMB SCOE deve ter vida útil >= 10 anos P D Press_25 Tempo estimado de uso dado considerando pelo menos 3 satélites

MOE Alimentação O UMB SCOE deve ser alimentado de acordo com AD01 e RD03 I M MOE Segurança O UMB SCOE deve atender requisitos de segurança de acordo c RD02 D M

MOE Proteção ao satélite O UMB SCOE deve minimizar a probabilidade de falha e reduzir a gravidade dos efeitos de falha no satélite e nos F M Press_26 O satélite deve ter proteções nos sinais presentes no conector umbilical.

MOE Proteção ao satélite Circuito de proteção independente da função principal e independente para cada tipo de interface/sinal. F D

MOP Proteção ao satélite Os circuitos de proteção devem atuar em caso de deteção de falha em até 20 ms. P M Press_27 O satélite deve suportar condições de falhas por até 40 ms. MOE Proteção ao satélite No caso de detecção de falha, o UMB SCOE deve alarmar localmente e remotamente e manter as demais funções F M

Em caso de pane no software ou no computador e houver o reinício do software, o UMB SCOE deve inicializar em modo

seguro ao satélite, evitando a interrupção de funções vitais ao satélite. F M

303

Tabela 6.9 – Lista dos Pressupostos Pressu- Descrição

posto

Press_01

Press_02

Press_03

Press_04 Press_05 Press_06 Press_07

Press_08 Press_09 Press_10

Press_11

Press_12 Press_13

Press_14

Press_15

Press_16 Press_17

Press_18 Press_19

Press_20

Press_21

Press_22

Press_23

Press_24

Press_25 Press_26 Press_27 Press_28 Press_29 Press_30

O conector umbilical do satélite terá sinais considerados essenciais e necessários para as preparações para o lançamento.

O satélite possuir uma entrada de alimentação direta no barramento e protegida por um diodo. Outra possibilidade é de que todas as linhas de alimentação do SAG tenham derivação para o conector umbilical. Neste caso devido a quantidade de canais a energia será fornecida pelo SAS SCOE. Pulso de comando para alterar estado de relés liga/desliga de equipamentos que não possuem telecomando. Ex.: bateria, receptor TTC, computador de bordo, entre outros.

Os sinais vitais disponíveis no umbilical com impedância de <=100KOhm. Sinal de telemetria derivado da saída do OBC sem modulação de RF.

Sinal de telecomando diretamente na entrado do OBC sem modulação de RF.

Sinais vitais presentes no umbilical que indiquem o funcionamento do barramento e estado ligado/desligado dos subsistemas essenciais.

Monitorar os sinais essenciais para tomada de decisão baseado em valores limites. Detecção e minimização de anomalia com efeito catastrófico e para eventos programáveis

Minimizar ao máximo a intervenção local no UMB SCOE. Exceto conectar e ligar o UMB SCOE, todas as outras operações serão controladas remotamente pelo OCOE.

A prioridade local deve ser maior que a remota para o caso de falha do link de comunicação. O operação remota nunca deve estar bloqueada.

A proteção por senha para evitar operação local por pessoas desabilitadas

Facilitar a aferição de calibração dos equipamentos para evitar que o UMB SCOE seja desmontado ou desconfigurado. Minimizar o tempo gasto na aferição.

Evitar que o UMB SCOE entre em modo calibração durante operação normal e comprometer a atividade.

Facilitar a movimentação do satélite sem a necessidade de utilizar o SAS SCOE em todas as etapas do AIT e lançamento. Para isso o PSS do satélite deve possuir entrada diretamente conectada no barramento do satélite.

Distância elétrica entre o satélite e o UMB SCOE durante lançamento: 70metros.

Alimentação conectada diretamente no barramento deve ser protegido de sobre-tensão. Para o caso de curto o PSS do satélite deve ter um diodo de proteção na entrada do barramento.

Para self-test de interface, será necessário um simulador de interface do satélite.

No modo simulação o software do UMB SCOE responde remotamente simulando que a operação foi executada, mas sem utilizar o hardware.

O UMB SCOE deve utilizar padrão de rack-container do EGSE, onde o rack possui tampas que fechadas viram um container para transporte, evitando a necessidade de colocar os racks em containers.

O UMB SCOE deve ficar ao lado do satélite durante o AIT, por isso deve respeitar restrições de áreas limpas. Durante o lançamento o UMB SCOE ficará na torre de lançamentos e deve respeitar restrições de segurança do lançador.

Tarefas repetitivas devem ser automatizadas localmente. Ex. : monitoração, self-test, sequencias de comandos disparadas por eventos.

Sequencias de eventos são geradas conforme necessidade e não devem fazer parte do código fonte e sim de arquivos texto gravados localmente.

Em caso de falha do computador ou falha de alimentação, o UMB SCOE deve retornar automaticamente em modo seguro e conhecido para evitar dano ou condição que possa induzir o operador a ação que ponha em risco o satélite e os outros elementos do EGSE.

Tempo estimado de uso considerando AIT e lançamento de pelo menos 4 satélites. O satélite deve ter proteções nos sinais presentes no conector umbilical.

O satélite deve suportar condições de falhas por até 40 ms. O UMB SCOE decodifica TM

O UMB SCOE codifica TC.

Distância do UMB SCOE ao TTC SCOE não pode exceder 20 metros

304

Da matriz MoE e seus pressupostos classificados para produto é possível compilar o documento de requisitos técnicos para o produto UMB SCOE.

Os requisitos dos stakeholders e seus pressupostos classificados para

processo e organização é possível compilar o documento de requisitos técnicos para os processos dentro do esforço de desenvolvimento do UMB SCOE.

6.5.4 Análise Funcional UMB SCOE – GS3

Com os requisitos técnicos do UMB SCOE previamente identificados, a análise funcional começa com a identificação dos limites funcionais do UMB SCOE.

6.5.4.1 Identificar as Fronteiras e Interfaces do UMB SCOE

Para identificar as fronteiras dos sistema são escolhidos os cenários relevantes dentro do ciclo de vido do UMB SCOE conforme mostra a Figura 6.12. A Tabela 6.10 resume os cenários relevantes e as circunstâncias de cada cenário relevante. A circunstâncias são analisadas da Figura 6.26 à Figura 6.30

Tabela 6.10 – Cenários Relevantes do UMB SCOE e suas Circunstâncias

305

Dos cenários relevantes e suas circunstâncias são levantados os eventos, estímulos e as respostas esperadas do produto UMB SCOE. Eventos e estímulos geram as respostas do UMB SCOE, que são analisadas na Seção 6.5.4.2.

Figura 6.26 – Modelagem de Ambiente do Cenário U11 e suas Circunstâncias

Figura 6.27 – Modelagem de Ambiente do Cenário U13 e suas Circunstâncias

306

Figura 6.28 – Modelagem de Ambiente do Cenário U31 e suas Circunstâncias

Figura 6.29 – Modelagem de Ambiente do Cenário U32 e suas Circunstâncias

Figura 6.30 – Modelagem de Ambiente do Cenário U33 e suas Circunstâncias

307

A partir da análise das circunstâncias é possível identificar as respostas esperadas do sistema conforme pode ser observado na Tabela 6.11.

Tabela 6.11 – Eventos e Estímulos e as Repostas do UMB SCOE

6.5.4.2 Definir Funções

Para cada cenário e circunstância identificados, conforme Tabela 6.12, são levantados todos os fluxos de energia, matéria e dados. Analisando os fluxos juntamente com as MoE funcionais são identificadas as funções externas do UMB SCOE conforme Tabela 6.13.

308

Tabela 6.12 – Lista de Fluxos Identificados em Cada Circunstância

309

Tabela 6.13 – Eventos e MoEs e Funções

Funções Externas do UMB SCOE:

F1 – Fazer Interface com satélite através do conector umbilical:

UMB SCOE deve ser interface do EGSE com o conector umbilical do satélite durante AIT e lançamento.

F2 – Proteger Satélite:

Minimizar a propagação de falha e reduzir a gravidade dos efeitos de falha no satélite e nos outros elementos do EGSE.

F3 – Monitorar Sinais:

Monitorar sinais vitais do satélite presentes no conector umbilical e sinais importantes ao estado do satélite incluindo sinais do EGSE.

F4 – Comandar:

Gerar pulso de comando ligar/desligar para o satélite via cabo umbilical, ou via dispositivos de simulação (ex.: simulação de separação)

F5 – Automatizar tarefas:

Automatizar tarefas baseadas em eventos decorrentes de monitoração e comando. Registrar eventos periodicamente, ou após eventos, gerar comandos decorrentes de eventos pré-definidos, entre outros.

310

F6 – Gerar Alarme:

Gerar alarme sonoro ou visual em decorrência de evento notórios pré-determinados.

F7 – Prover Interface Local interativa:

Prover interface gráfica/sinóptica com o usuário local. Possibilitar edição de parâmetros de configuração interno, gravar ou recuperar configuração, durante operação. Prover visualização de valores e estado de monitoração.

F8 – Prover Interface Remota:

Prover operação remota e simultaneamente ao modo Local.

F9 – Alimentar Satélite:

Prover alimentação própria ou via SAS para o satélite durante as atividades de AIT e lançamento

F10 – Simular Operação:

Possibilitar a simulação da interface com o satélite e verificação das funções do UMB SCOE por meio do Simulador de Satélite (Auto-teste)

Prover adicionalmente o modo de simulação de software para teste de interface remota e validação de procedimentos (scripts).

F11 – Auxiliar Calibração:

Prover modo para agilizar e automatizar a calibração dos instrumentos por meio de interface especial de hardware e software

F12 – Proteger do ambiente:

Proteger os elemento do UMB SCOE contra EMC, impacto, vibração, poeira e humidade de acordo com AD01 e AD04

F13 – Rotear:

Rotear sinais do conector umbilical ao demais elementos do EGSE que fazem interface com o UMB SCOE: PSS SCOE (SAS), OCOE, TTC SCOE.

F14 – Converter TM:

Converter sinal de TM da interface física RS-422 (PCM / NRZ-L) ESA-PSS-04-106 (ECSS,1988) para frame de TM exportado via LAN

F15 – Converter TC:

Converter frame TC recebido via LAN para interfaces física RS-422 (PCM / NRZ-L) ESA-PSS-04-107 (ECSS,1992)

6.5.4.3 Análise de Escopo Funcional

O objetivo da análise de escopo funcional é capturar os limites e o escopo funcional por meio de diagramas que identificam os elementos e fluxos dos

311

sistemas que interagem com o UMB SCOE. Ao final deste processo será possível identificar as interfaces externas com do UMB SCOE.

A análise do escopo de cada função ajuda a identificar as entradas e saídas das funções.

Figura 6.31 – Análise de Escopo das Funções F1, F2, F3 e F4 do UMB SCOE

312

Figura 6.32 – Análise de Escopo das Funções F5,F6,F7 e F8 do UMB SCOE

Figura 6.33 – Análise de Escopo das Funções F9, F10, F11, F12 e F13 do UMB SCOE

313

A partir da análise das entradas e saídas de cada função é possível estabelecer as interfaces entre as funções. A Figura 6.34 mostra o gráfico N2 para as funções UMB SCOE. O principal objetivo do gráfico N2 é indicar as interações entre as funções do sistema e com o ambiente.

Das 15 funções inicialmente levantadas, é possível observar que duas funções: F2 “Proteger Satélite” e F5 “Automatizar Tarefas” não possuem interface com os sistemas externos portanto são funções internas ao UMB SCOE

Figura 6.34 – Gráfico N2 – Identificação das Interfaces funcionais

314

6.5.4.4 Definir Estados e Modos

A partir da identificação das funções, estados e modos são identificados para cada função externa ao UMB SCOE conforme Tabela 6.14.

Tabela 6.14 – Estado e modos do UMB SCOE

315

6.5.4.5 Análise de Comportamento Funcional

Estados e modos identificados, são então refinados a partir do diagrama de transição de estados desenvolvido para cada função externa ao UMB SCOE mostrados nos diagramas da Figura 6.35 à Figura 6.38.

Figura 6.35 – Diagrama de Transição de Estados das Funções F2, F3 e F4

316

Figura 6.36 – Diagramas de transição de Estados da função F6

Figura 6.37 – Diagramas de Transição de Estados das Funções F7, F8 e F9

317

Figura 6.38 – Diagramas de Transição de Estados das Funções F10 e F11

Durante a análise de comportamento funcional, é possível Identificar as possíveis falhas em cada um dos fluxos e com isso Identificar funções preventivas e protetivas para as falhas.

Arquitetura funcional irá mostrar graficamente como as funções interagem

6.5.4.6 Estabelecer a Arquitetura Funcional do UMB SCOE

A Figura 6.39 e Figura 6.40 mostram a arquitetura funcional relacionadas às funções F3 “Monitorar” e F4 “Comandar” respectivamente.

318

Figura 6.39 – Arquitetura Funcional: Monitoração

319

Figura 6.40 – Arquitetura Funcional: Comandar Satélite

A modelagem de arquitetura funcional prossegue para todas a funções identificadas. Dessa forma a arquitetura funcional do UMB SCOE é proposta e documentada em forma de diagramas.

O processo prossegue então para a análise de implementação onde são identificados os produtos abaixo na hierarquia, e alocados as funções.

Para cada produto do nível abaixo é necessário tomar a decisão de desenvolvimento, aquisição ou reuso.

320

7 Discussão

Este capítulo tem como objetivo fazer uma análise da aplicação do guia proposto no capítulo 5 e mostrar de forma objetiva um comparativo do desenvolvimento de GSE com e sem a aplicação do guia proposto, suas dificuldades e limitações.

O guia desta dissertação tem como objetivo auxiliar desenvolvedores de produtos espaciais, de processo de AIT e de GSE nas considerações a serem tomadas para o desenvolvimento de GSE.

O guia deve ser usado como uma referência inicial, abrangente , indicando e sugerindo outras referências mais específicas e aplicáveis à engenharia de sistemas, à modelagem de sistema, à gerenciamento de projetos e a normas técnicas relacionadas aos equipamentos de suporte.

Este capítulo está estruturado da seguinte forma:

Análise do guia à luz da fundamentação teórica; · Comparação com a prática no satélite PMM;
Análise crítica do Guia; · Limitações do Guia.

7.1 Comparação com elementos da fundamentação teórica

O objetivo desta seção é fazer uma análise da fundamentação teórica referenciada neste trabalho.

7.1.1 Engenharia Simultânea

Embora as normas e manuais de engenharia de sistemas, consultados e recomendadas por esta dissertação no Capítulo 5, incorporem a abordagem simultânea no desenvolvimento de sistemas, quando se analisa com mais detalhes suas diretivas e atividades, principalmente com relação a desenvolvimento de processos do ciclo de vida e consequentemente de produtos de apoio, é que se percebe que abordagem simultânea sugerida é mais voluntária do que compulsória, conforme esta dissertação propõe.

321

Conforme visto na Seção 2.2, o manual de engenharia de sistemas da NASA (NASA,2007) sugere a aplicação do Motor SE, i.e., dos processos de design, processos de realização e dos processo de gerenciamento técnico de forma concorrente já nos conceitos iniciais, por meio de modelagem, simulações, maquetes entre outras. O manual incorpora a abordagem simultânea, embora não mencione explicitamente como mencionava na edição de 1995 (NASA.1995). Porém, analisando as atividades prescritas nas fases do ciclo de vida observa-se que o Plano de Verificação somente aparece na fase B e a preparação da integração somente tem início na fase C (NASA,2007,pg 24)

Na descrição das atividades da fase C, o manual da NASA (2007) reforça a necessidade de que para cada refinamento do “design final”, “as atividades de integração e verificação devam ser planejadas em detalhes” (NASA,2007,pg 25). Ou seja apesar da abordagem simultânea estar presente no Motor SE, a descrição das atividades das fases não esta em sintonia e usa termos como “planejar” após o refinamento do design “final”, contrariando a abordagem simultânea e contrariando a abordagem desta dissertação que considera que o design do produto de interesse deve necessariamente considerar o desde o início os processos do ciclo de vida e por consequência os produtos de apoio que o viabilizam.

7.1.2 Processos do Ciclo de Vida e Produtos de Apoio

A NASA (2007) considera que produtos de interesse e produtos de apoio são interdependentes e são visto como um sistema. Dentro dessa visão, os requisitos dos produtos de apoio devem fazer parte do pacote de dados de saída do Processo de Definição de Solução de Projeto. Nessa abordagem, a NASA (2007) reconhece que produtos de apoio dependem da solução de design do produto espacial, conforme hipótese levantada por esta dissertação, mas a abordagem da NASA não trata dessa interdependência ao não desenvolver explicitamente os processos do ciclo de vida simultaneamente para possibilitar derivar os requisitos dos produtos de apoio. Ao invés disso, no

322

WBS, associa produtos de apoio aos produtos de interesse e lista serviços tais como gerenciamento, engenharia, fabricação, verificação e assim por diante.

Já a norma IEEE-Std-1220 (IEEE,2005, pg18) sugere a integração simultânea do desenvolvimento do produto e seus processos do ciclo de vida. Apesar disso, e embora esteja em sua apresentação, há poucas diretivas ao longo do documento relacionadas à desenvolvimento de processos e o enfoque maior é dado à definição dos produtos do sistema. Segundo a norma, o Processo de Engenharia de Sistemas – SEP é aplicável aos produtos e processos do ciclo de vida, mas analisando seus sub-processos e tarefas, o SEP é claramente focado no desenvolvimento de produto, e parece destoar da estrutura “building block”.

Por sua vez, a norma ISO/IEC15288 (ISO,2008) utiliza uma nomenclatura um pouco diferente da norma IEEE-Std-1220 (IEEE,2005). Para ISO/IEC15288: 2005 “Sistemas de Apoio são visto como provedores de serviços essenciais ao “Sistema de Interesse mas que não contribuem diretamente com o ambiente operacional”. A partir desse conceito, os Processos Técnicos, definidos na norma ISO/IEC15288: 2005 e apresentados na Seção 2.4.5.4, deveriam ser aplicados igualmente aos Sistema de Interesse e aos Sistemas de Apoio. Mas a recursividade dos Processos Técnicos são voltados para produto que possui ciclo de vida. Ou seja cada produto tem seu próprio ciclo de vida. Portanto a norma é aplicável para desenvolvimento de produtos. Os processos do ciclo de vida são vistos no desenvolvimento do produto. Não há diretiva para desenvolvimento dos processos.

Mesmo sendo focada para desenvolvimento de produtos e dos processos do ciclo de vida, a norma ISO/IEC15288:2008 considera os processos do ciclo de vida do produto apenas como restrições impostas ao produto conforme observado nas Seções 2.4.5.4.1, 2.4.5.4.2 e 2.4.5.4.3, apontando a possibilidade de sistemas de apoio imporem requisitos de acessibilidade e interface ao sistema de interesse, porém não levanta a possibilidade de os sistemas de apoio imporem requisitos funcionais ao sistema de interesse.

323

7.2 Comparação com a Prática do Programa PMM

Uma forma de demonstrar a aplicabilidade do Processo de Desenvolvimento de Integrado do GSE é comparar a solução de um elemento do GSE desenvolvido com e sem a aplicação do processo PDIG proposto. Para esta comparação foi escolhido o EGSE do programa PMM.

A comparação será feita entre o UMB SCOE analisado pelo processo PDIG, com o SCS SCOE especificado para o satélite Amanzonia-1, apresentado na Seção 4.4.3.

O SCS SCOE idealizado para o satélite Amazonia-1 é o elemento do EGSE que reúne todos os meios para fazer interface com satélite, via cabo umbilical durante operação normal e através de conectores internos via terminais facilitadores chamados de BOB (Break-Out Box) que permite acesso a qualquer tipo de conector interno por meio da utilização de cabos adaptadores (INPE,2015a).

O SCS SCOE foi especificado no documento de especificação do EGSE para o satélite Amazonia-1 (INPE,2015a) pouco tempo antes deste trabalho ser elaborado. Quando foi iniciada a análise do UMB SCOE, o autor não tinha conhecimento do documento especificação do EGSE para o satélite Amazonia-1 (INPE,2015a) e somente veio a ter acesso ao documento após a análise do UMB SCOE mostrado no Capítulo 6.

Por outro lado, o UMB SCOE foi elaborado baseado nos requisitos levantados da revisão bibliográfica do EGSE do programa CBERS 3&4, no qual o autor foi responsável pelo desenvolvimento do GWC SCOE.

Os dois equipamentos, SCS SCOE (INPE,2015a) e o UMB SCOE (exemplo do Capítulo 6) guardam algumas diferenças de escopo que serão exploradas nas seções seguintes.

O UMB SCOE foi idealizado para ser o único elemento do EGSE conectado ao satélite durante o lançamento para um satélite com características do

324

Amazonia-1 do programa PMM, conforme pode ser visto pela análise dos requisitos de stakeholders da Seção 6.5.2.

No processo de análise do UMB SCOE, foram pesados os requisitos de stakeholders e suas Medidas de Efetividade – MoEs, fazendo com que alguns atributos emergissem tais como: único elemento com interface com o satélite via umbilical, transportabilidade, facilidade de instalação, segurança, imune a falhas, regras na base de lançamento fossem pesados e obrigatoriamente considerados na solução.

Obviamente nessa comparação não será possível fazer juízo de valores pois

apesar de ambos os elementos desta comparação possuírem muitas semelhanças funcionais, foram idealizados com missões diferentes, i.e., a missão do SCS SCOE, é mais voltada para as atividades de AIT com foco no início da integração do satélite, quando há necessidade de muita intervenção elétrica no satélite, ao passo que a missão do UMB SCOE é mais voltada para a operação do satélite, principalmente durante os preparativos para o lançamento.

A operação do UMB SCOE durante lançamento do satélite é uma atividade

considerada crítica do ponto de vista técnico e logístico. É crítico do ponto de vista técnico pois qualquer falha do UMB SCOE poderia causar uma falha no satélite ou no mínimo abortar o lançamento. É critico do ponto de vista logístico pois bases de lançamento impõem muitos requisitos e restrições quanto a espaço, consumo de potência e segurança que restringem as soluções.

Um importante ponto a ser considerado é o atual estágio do projeto do SCS SCOE especificado para Amazonia-1, que atualmente está em fase de implementação, mas nem todos seus requisitos estão especificados, o que demonstra que a hipótese de que um produto de apoio possui design acoplado ao produto de interesse, levantada no na Seção 1.1.1 é válida.

Outro ponto a ser considerado nesta comparação é que, como visto na Seção 4.4.3 o SCS SCOE possui apenas uma missão e alguns requisitos de alto nível

325

demandados no documento de especificação do EGSE para o satélite Amazonia-1 (INPE,2015a), em contrapartida o UMB SCOE, analisado pelo processo PDIG no Capítulo 6, não está muito diferente já que a análise apenas levantou requisitos funcionais de alto nível, fazendo com que esta comparação se torne bastante interessante e abrindo espaço, se houver interesse, deste trabalho influenciar as decisões futuras de implementação do SCS SCOE.

A Tabela 7.1 mostra uma matriz de comparação das funções alocadas ao SCS SCOE no documento de especificação do EGSE (INPE,2015a) com as funções externas do UMB SCOE identificadas pelo processo de análise funcional do UMB SCOE mostradas na Seção 6.5.4.2.

326

Tabela 7.1 – Matriz de Correspondência Funcional do SCS SCOE com o UMB SCOE

Matriz de comparação das funções definidas para o SCS SCOE no documento de especificação do EGSE do Amazonia-1 (AMAZONIA,2015a) com as funções externas levantadas para o UMB SCOE no exemplo do Capítulo 6.

327

7.2.1 Funções Adicionais Identificadas no UMB SCOE pelo PDIG

Esta seção apresenta uma análise das funções especificadas para o UMB SCOE e que não foram especificadas para o SCS SCOE.

Foram identificadas 4 funções no UMB SCOE que não foram especificadas para o SCS SCOE:

Função alimentar o satélite (F9); 2. Função auxiliar a calibração (F11); 3. Função decodificar TM (F14);
Função codificar TC (F15).

Essas diferenças funcionais entre o SCS SCOE e UMB SCOE podem exemplificar à aplicação do guia proposto nesta dissertação.

A função alimentar o satélite não está presente nos requisitos para o SCS

SCOE, pois o EGSE do Amazonia-1 foi especificado após a definição do modelo EM do satélite Amazonia-1 e sem a definição detalhada do processo de AIT, em um processo de engenharia de sistemas tradicional baseado na estrutura hierárquica top-down de produtos, onde não há um mecanismo que permita que o design do satélite seja realimentado por necessidades advindas do EGSE, que por sua vez é decorrente da análise dos processos não operacionais do ciclo de vida do satélite: o processo de AIT. A Seção 7.2.1.1 mostra como o guia de desenvolvimento de GSE correlaciona a definição do GSE com o desenvolvimento do produto espacial.

A função auxiliar a calibração, por sua vez, é o resultado direto da aplicação do Processo de Desenvolvimento Integrado do GSE – PDIG que baseado no Processo de Análise Estruturada de Sistema – PAES possibilita identificar e balancear requisitos dos stakeholders não apenas do produto UMB SCOE mas também dos seus processos do ciclo de vida. Ao simultaneamente analisar os cenários do ciclo de vida, o PAES permite agregar valor ao produto em desenvolvimento por meio das Medidas de Efetividades – MoE dos requisitos dos stakeholders mesmo que sejam requisitos desejáveis e não mandatórios. A Seção 7.2.1.2 mostra de forma sintética como a análise de stakeholders inicial evoluiu para uma função de auxilio à calibração no UMB SCOE.

328

Por outro lado a alocação das funções de decodificar TM e codificar TC no UMB SCOE em contrapartida da alocação do EGSE do Amazonia-1, é resultado da evolução de design do EGSE que o PDIG estimula ao identificar correlação entre o desenvolvimento do EGSE de sistema com o desenvolvimento do processo de AIT no cenário de lançamento do satélite, somado ao emprego da metodologia de análise estruturada PAES. A Seção 7.2.1.3 mostra essa análise.

7.2.1.1 Função Alimentar Satélite

Função “Alimentar o Satélite” é decorrente do balanço de vários requisitos de

stakeholders nos cenários relevantes de operação feitos na Seção 6.5.2.4.1 e reproduzido parcialmente na Tabela 7.2. As preocupações dos stakeholders foram mapeadas para a Medida de Efetividade MOE_007 levantada na análise de requisitos do UMB SCOE da Seção 6.5.2.5 e reproduzido na Tabela 7.3.

Tabela 7.2 Stakeholders e suas Preocupações Relacionados com a Medida de Efetividade MOE_007

Stakeholders	Cenários	Preocupações
SAT.DESV	U0	Proteger o satélite; Funções vitais em AIT e lançamento; Confiabilidade.
SAT.SYS	U32	Única interface elétrica com EGSE; Sinais vitais: Energia, Monitoração, Controle
SAT.EGSE. Responsável	U33	Transportabilidade; Alimentar o satélite.
SAT.DESV	U33	Sinais Vitais; Bateria Carregada/Monitorada;

Cenários do Ciclo de Vida: U0: Desenvolvimento; U32: Operação em AIT; U33: Operação em Lançamento

Tabela 7.3 – Medida de Efetividade MOE_007 Relacionada como a Função Alimentar Satélite (F9)

MOE	Descrição	Nível
MOE_007	Prover alimentação para o satélite durante as atividades de AIT e lançamento	M
MOE_007.1	Alimentar o satélite com potência suficiente para executar todas operações do satélite	M
MOE_007.2	Ser capaz de carregar a bateria do satélite	M

329

MOE

Descrição

Nível

MOE_007.3

Compensar a perda de tensão causada pelo cabo umbilical de 70 metros

MOE_007.4

Proteger o satélite contra sobre-tensão

Nível de Atendimento: M=Mandatório; D=Desejável, O=Opcional.

Ao analisar os requisitos de stakeholders, são levantando alguns pressupostos relacionados. Para o MOE_007 – Alimentar satélite, três pressupostos foram levantados na Seção 6.5.3 de análise de requisitos do UMB SCOE:

Pressuposto 15:

Pressuposto 16:

Distância elétrica entre o satélite e o UMB SCOE durante lançamento: 70metros.

Pressuposto 17:

Alimentação conectada diretamente no barramento deve ser protegido de sobre-tensão. Para o caso de curto o PSS do satélite deve ter um diodo de proteção na entrada do barramento.

Os pressupostos 15 e 17 apontam para requisitos para o subsistema PSS e para a cablagem do satélite conforme descrito no “loop de verificação” do satélite e discutido na Seção 5.4.1.

Para que seja possível alimentar o satélite com uma fonte interna ao UMB SCOE é necessário que o satélite forneça uma interface e função correlacionada. Ou seja o processo de AIT juntamente com a definição do GSE realimentam a análise de requisitos do satélite reforçando assim necessidade de desenvolvimento simultâneo do satélite, seu processo de AIT e o GSE necessário.

7.2.1.2 Função Auxiliar a Calibração

Como parte do processo de análise de stakeholders do cenários U34 “Operação durante calibração”, desdobrado na Figura 6.21, os interesses do stakeholders são traduzidos para a medida de efetividade MOE_006

330

reproduzida na Tabela 7.4. Dessa forma a função de auxílio a calibração é identificada na análise de requisitos, juntamente com condições, restrições e pressupostos, conforme pode ser observado nos pressupostos 13 e 14 a seguir:

Pressuposto 13:

Facilitar a aferição de calibração dos equipamentos para evitar que o UMB SCOE seja desmontado ou desconfigurado.

Minimizar o tempo gasto na aferição. 2. Pressuposto 14:

Evitar que o UMB SCOE entre em modo calibração durante operação normal e comprometer a atividade.

Tabela 7.4 – MOE_006 – Medida de Efetividade relacionada como a função F11 – Auxiliar Calibração

MOE	Descrição	Nível
MOE_006	Função interna de auxílio a calibração.	D
MOE_006.1	Modo calibração protegido por senha.	D
MOE_006.2	Interface elétrica de fácil acesso.	D

Nível de Atendimento: M=Mandatório; D=Desejável, O=Opcional.

O pressuposto 13 está relacionado com a maximização da disponibilidade do

UMB SCOE para operação, cuja razão vem do fato de que o UMB SCOE ser a única interface do EGSE com o satélite pelo cabo umbilical, tornando-o imprescindível para as atividades elétricas no satélite.

Outro fator relacionado ao pressuposto 13, é quanto a segurança implícita em

“facilitar a calibração”, já que sem uma função específica para calibração pode haver a necessidade de retirada dos instrumentos para a calibração, aumentando o risco de falha no processo. Cabe lembrar que a retirada de equipamento e a posterior remontagem, implicaria em um processo de validação do UMB SCOE (U31 na Figura 6.12) mais elaborado, pois não apenas as interfaces do UMB SCOE seriam verificadas, mas todas as funções operacionais.

Por outro lado, a razão de o pressuposto 14 estar relacionado com a segurança

da implementação da função extra de auxílio a calibração, cuja preocupação é

331

a de que o UMB SCOE não entre em modo calibração indesejavelmente por falha ou erro de operação. Esse balanço dos requisitos de stakeholders e pressupostos é resultado da análise de requisitos, o que justifica o nível de atendimento considerado apenas “desejável” na Tabela 7.4.

Concluindo, com o acréscimo de funcionalidade ao produto UMB SCOE para auxiliar a aferição de calibração (processo do ciclo de vida do UMB SCOE) é possível evitar a desmontagem de seus equipamentos, evitando assim a indisponibilidade do UMB SCOE para o processo de AIT. Essa conclusão somente é possível balanceando requisitos dos stakeholders do processo do ciclo de vida do UMB SCOE, do processo de AIT e do produto UMB SCOE simultaneamente, conforme o processo PDIG enfatiza.

7.2.1.3 Funções de Conversão TM e TC

A função decodificação TM (F14) e a função de codificação TC (F15) alocadas para o UMB SCOE é o resultado da análise de implementação do EGSE discutida na Seção 6.4.

A diferença entre UMB SCOE do exemplo do Capítulo 6 e o SCS SCOE é meramente uma questão de diferença de alocação de funções na implementação do EGSE. Essas funções não aparecem nos requisitos do SCS SCOE no documento de especificação do EGSE para o satélite Amazonia-1 (INPE,2015a) mas aparecem no OBDH SCOE, detalhadamente descritas e reproduzidas na Tabela 4.8 e na Figura 4.23.

O motivo dessa diferença de alocação de funções está relacionado com o balanço dos requisitos de stakeholders juntamente com condições, restrições e pressupostos.

A função rotear (F13) está diretamente relacionada com a medida de efetividade MOE_19 que por sua vez é a conjunção de três MOEs relacionadas com as interfaces do UMB SCOE com o restante o EGSE conforme Tabela 7.5.

332

Analisando os fluxos da função F13 na Figura 6.33 é identificado que os fluxos de TM e TC para o OCOE são diferentes dos fluxos de TM e TC do satélite e do TTC SCOE.

Juntamente com os MOEs, são levantadas as condições e restrições nos

seguintes pressupostos:

Pressuposto 28: Prover Decodificação TM; 2. Pressuposto 29: Prover Codificação TC;
Pressuposto 30: Distância do UMB SCOE ao TTC SCOE não pode exceder 20 metros.

Tabela 7.5 – Medida de Efetividade relacionada como a função F13 – Rotear

MOE	Descrição	Nível
MOE_019	Rotear sinais ao EGSE	M
MOE_019.1	Interfacear com SAS SCOE (linhas dedicadas de potência)	M
MOE_019.2	Interfacear com OCOE (TMTC – LAN)	M
MOE_019.3	Interfacer com TTC SCOE (TMTC – RS-422)	M

Os pressupostos 28 e 29 isoladamente não justificam a alocação dessas

funçõ