Synthesis and more João Borges de Sousa DEEC [email protected] Mestrado em Engenharia Electrotécnica e de Computatadores 1 Outline • SE process: recap • Synthesis • What’s next? • Final comments J. Borges de Sousa SE process J. Borges de Sousa System = products + processes Source: IEEE Std 1220 - 2005 Systems Engineering Process (SEP) Generic problem-solving process, which provides the mechanisms for identifying and evolving the product and process definitions of a system. Applies throughout the system life cycle System life cycle IEEE Std 1220-2005 Hughes SE Handbook MIL-Std-499B (DoD) Pre-Concept Exploration Pre-Concept Exploration Preliminary Design Concept Exploration and Concept Exploration and Development Development Demonstration and Demonstration and Validation Validation Design Alloaction Detailed Design System Preliminary Design System Definition Fabrication, Assembly, Integration and Test Detailed Design Design Implementation Production Production Costumer Support Engineering and Manufacturing Deployment Production and Deployement Operations and Support Operations and Support Disposal Disposal System Breakdown Structure (SBS) Hierarchy of products and processes that comprise the system architecture. Source: IEEE Std 1220 - 2005 Example: UXV system breakdown structure Level 1 Level 2 Vehicle Frame Propulsion (power/thrust, energy harvesting) Communications/Identification Navigation/Guidance Computer Auxiliary Equipment Application Software System Software Interoperability (software/hardware) Survivability Sensors Communications Remote Sensor System Delivery Application Software System Software Interoperability (software/hardware) Command and Control Subsystem Communication systems Launch and Recovery Equipment Transport System Components Application Software System Software Interoperability (software/hardware) Payload Control station Specification tree • Modeled design architecture appropriate to level of development. • Composed of specification elements and interface specifications. • System interface specifications define interfaces with external systems, platforms, and products. • Subsystem interface specifications define interfaces among subsystems, including hardware-hardware, hardware-software, software-software, human-human, human-hardware, and human-software interfaces. • Developed top down. • The number of levels of a specification tree depends on the stage of the life cycle • Lowest level of the specification tree is dependent upon the complexity of the design element and to what level the decision can be made to make, buy, or reuse the product associated with the specification. Source: IEEE Std 1220 - 2005 Análise e Especificação de Requisitos Esta fase decompõe-se em duas actividades principais: Necessidade Analisar as necessidades Análise e Especificação de Requisitos Requisitos de utilizador/marketing Especificar requisitos Concepção do Sistema Requisitos de engenharia Tipos de requisitos • Uma classificação muito simples • Requisitos funcionais → especificam aquilo que é suposto o sistema fazer • Requisitos não funcionais → incluem todas as outras características e restrições que o sistema deve respeitar • Classificação mais detalhada dos requisitos não funcionais. • Desempenho (ou performance) → especificam características relativas a aspectos como o tempo de resposta, precisão, fiabilidade, etc. • Interfaces externas → especificam com quem (sistemas ou pessoas) interactua o sistema e como se processam essas interacções. • Restrições → decisões prévias que impõem limitações ao projecto como a linguagem de programação, o sistema operativo, o microprocessador, o fabricante dos equipamentos, etc. • Custo → Podem aplicar-se tanto aos custos de desenvolvimento do sistema, como aos custos de produção do produto na fase de comercialização. • Energia → Tipicamente são relativos ao consumo ou ao rendimento energético do sistema. • Ambiente → Tanto se podem relacionar com a utilziação de recursos naturais (energéticos e matérias primas) como com a reciclagem de materiais que compõem o sistema. • Higiene e Segurança → Prendem-se com questões de ergonomia, higiene e segurança na utilização do sistema. • Outros requisitos e propriedades do sistema → outros requisitos ou caracterísiticas gerais que o sistema deva possuir Functional architecture • Describe the problem (requirements analysis) in more detail • Decompose system functions to lower-level functions • Translate the requirements baseline into a functional architecture • Useful technique: chair flying ☺ • https://www.youtube.com/results?s earch_query=blue+angels+chair+flyi ng Source: IEEE Std 1220 - 2005 System concept • Establish system definition • • • • • Complete specifications • • • • • Select system concept Identify sub-systems and sub-systems interfaces Identify human/system interface issues Revise engineering and technical plans for preliminary design System and product interface specs Sub-system interface specifications Preliminar sub-system specs Human/system interface Establish baselines • Establish system baseline • Establish preliminary sub-system design to baselines • Complete technical reviews • Complete alternative concept review • Comple system definition review A few questions • What about solutions? • Hardware, software, etc... • What about processes? J. Borges de Sousa Synthesis J. Borges de Sousa What? • Define design solutions • Identify subsystems (satisfy requirements) • Define system elements • Decomposition, interfaces and design constraints • Translate functional architecture into design/physical architecture Source: IEEE Std 1220 - 2005 6.5.1 Group and allocate functions • The project groups common functions and subfunctions of the verified functional architecture into logical functional elements in a manner that permits their allocation to design elements. • Requirements traceability is established and recorded to ensure that all functions are allocated to elements of the system; each system element performs at least one function. 6.5.2 Identify design solution alternatives • The project generates alternative design solutions for the functional elements identified in 6.5.1. These solutions should be composed of one or more of the following: hardware, software, material, data, facility, people, and techniques. 6.5.3 Assess safety and environmental hazards • The project analyzes alternatives of 6.5.2, and aggregates of alternatives, to identify potential hazards to the system, humans involved in the system and supporting the system life cycle processes, or the environment. 6.5.4 Assess life cycle quality factors • The project assesses alternatives of 6.5.2 to determine the degree to which quality factors (producibility, testability, ease of distribution, usability, supportability, trainability, and disposability) have been included in the solutions. 6.5.5 Assess technology requirements • The project assesses alternatives of 6.5.2 to determine the technological needs necessary to make the design solution effective. • The risks associated with the introduction of any new or advanced technologies to meet requirements should be identified and assessed. • Training and personnel pipelines should also be evaluated to ensure that they meet the specified requirements. 6.5.6 Define design and performance characteristics • The project identifies and documents the design and performance characteristics of design alternatives. • This includes the estimation or measurement of human physical and cognitive workload levels. characteristics and human-engineering elements associated with life cycle quality factors should be identified and assessed. J. Borges de Sousa Source: IEEE Std 1220 - 2005 6.5.7 Define physical interfaces • The project identifies and defines the physical interfaces among products, subsystems, humans, life cycle processes, and external interfaces to higher-level systems or interacting systems. 6.5.8 Identify standardization opportunities • The project analyzes alternatives of 6.5.2 to assess whether use of standardized end items would be technologically and economically feasible. 6.5.9 Identify off-the-shelf availability • The project analyzes alternatives of 6.5.2 to determine availability of an off-the-shelf item (nondevelopmental hardware or software). 6.5.10 Identify make-or-buy alternatives • The project performs economic analysis of design alternatives to support make-or-buy decisions. This analysis should address whether it is more cost-effective for the project to produce the design element vs. going to an established supplier. 6.5.11 Develop models and prototypes • The project develops models and/or prototypes to assist in the following: • • • a) Identifying and reducing risks associated with integrating available and emerging technologies b) Verifying that the design solution (made up of hardware, software, material, humans, facilities, techniques, data, and/or service) meets allocated functional and performance requirements, interface requirements, workload limitations, and constraints c) Verifying that the design solution satisfies functional architecture and requirements baseline requirements 6.5.12 Assess failure modes, effects, and criticality • The project assesses failure modes, the effects, and the criticality of failure for design alternatives. • The hardware, software, and human elements of the design alternatives should be analyzed, and historical or test data should be applied, to refine an estimate of the probability of successful performance of each alternative. 6.5.13 Assess testability needs • The project assesses the testability of design alternatives to determine built-in test (BIT) and/or fault isolation test (FIT) requirements to support operational or maintenance considerations. 6.5.14 Assess design capacity to evolve • The project assesses design alternatives to determine the capacity of the design solution to evolve or be reengineered, accommodate new technologies, enhance performance, increase functionality, or incorporate other cost-effective or competitive improvements once the system is in production or in the marketplace. J. Borges de Sousa Source: IEEE Std 1220 - 2005 Validation and verification Verification is the process for determining whether or not a product fulfills the requirements or specifications established for it. • Validation is the assessment of a planned or delivered system to meet the sponsor's operational need in the most realistic environment achievable. • Regardless of the life-cycle model our sponsors use, they all track to three basic systems engineering stages: concept development, engineering development, and post-development. Each of these engineering stages may be separated into supporting phases. The concept development phase is critical because it describes the ultimate operational requirements that will be used to "validate" the ultimate material solution. The supporting system, subsystem, and component level specifications leading to preliminary design and critical design will be iteratively verified through various types of testing and analysis during materialization, integration, and testing. Verification is the critical feedback element that confirms the specifications were satisfied. Validation is confirmation that the user's needs will be or are satisfied in the final material solution. It cannot be overemphasized that Verification and Validation (V&V) and Test and Evaluation (T&E) are not separate stages or phases, but integrated activities within the SE process. https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/testand-evaluation/verification-and-validation J. Borges de Sousa What’s next? J. Borges de Sousa So, what? Mini-test: : April 26th; Individual evaluation moment during presentation/demonstration (also “recurso” for those who failed mini-test) Two invited lectures March 22nd and March 29th (Highly recommended) •Humberto Ayres Pereira and Jorge Moreira da Silva What about your team and the challenge? •See the light at the end of the tunnel? •How do you relate what you are learning here to what you are doing in the project? •What have you done in terms of team building? Mid-term review: Week of the mid.term review report https://www.linkedin.com/pulse/build-winning-team-michael-d-brasseur What about the “shopping list”? J. Borges de Sousa System concept deliverable (Topics) • Overview of the challenge • System breakdown structure (first 2 levels) • List of engineering (functional, non-functional, etc) requirements (Annex) • Market survey (Annex) • Functional architecture (Annex) • Conclusions J. Borges de Sousa Mid-term report deliverable (Topics) • Description of the challenge • Validated requirements • Functional architecture • SBS • WBS • Risk management • Work done so far • KPIs • Budget J. Borges de Sousa Final remarks J. Borges de Sousa Change in an age of exponentials An analysis of the history of technology shows that technological change is exponential, contrary to the common-sense “intuitive linear” view. So, we won’t experience 100 years of progress in the 21st century — it will be more like 20,000 years of progress (at today’s rate). The “returns,” such as chip speed and cost-effectiveness, also increase exponentially ... Within a few decades, machine intelligence will surpass human intelligence, leading to The Singularity — technological change so rapid and profound it represents a rupture in the fabric of human history. The Law of Accelerating Returns, March 7, 2001, Ray Kurzweil J. Borges de Sousa Age of exponentials J. Borges de Sousa Funding for ideas Worldwide investors pursue sustainable goals through a great variety of strategies J. Borges de Sousa Principles “whatever success I had in life has more to with how to deal my knowing that I don’t know much what I need to know than anything else” Ray Dalio Brutal honesty Radical transparency https://www.principles.com/principles-for-success/#play https://www.ted.com/talks/ray_dalio_how_to_build_a_company_where_the_b est_ideas_win?language=en J. Borges de Sousa SE can help you make an impact Let’s engineer systems!!! J. Borges de Sousa
