0. Introduction – Architectural Design Within Systems Engineering
- the business case for a systems approach to design
- definition of terms
- design interactive exercise – basic
- systems engineering process overview – the football diagram
- design within a systems engineering process model
This short introduction presents the business case for systems engineering and a short overview of the systems engineering process to provide the context within which architectural design is conducted. The importance of architectural design is also highlighted.
1. Design-Related Principles of Engineering
- system views
- Workshop 1 – design-related principles
This module addresses key design principles starting with a whiteboard example and concluding with a workshop to establish an important foundation for what follows.
2. Styles of System Development (1.5 hours)
- the solution domain: key concepts, relationships, and work products
- waterfall, incremental, evolutionary and spiral development approaches
- Workshop 2 – solution development strategies for a product
This module deals with four basic styles of development as possible development strategies for a product depending on the associated requirements related risk and implementation related risk.
3. Concepts of Architecture and Detailed Design – Physical and Logical
- physical architecture (structural view) – basic concepts
- logical architecture – basic concepts
- logical architecture related to physical architecture
- useful forms of logical representation – functional, state-based, mathematical, hybrid, … with examples
- model-based design in practice – MBSE/MBA/MBD/MDA/MDD
This module introduces the basic concepts of architectural and detailed design. The module identifies multiple forms of logical design representation and establishes the relationships between logical architecture and physical architecture. The module concludes with the concepts of model-based and model-driven as applied within systems engineering.
4. Initial Physical Conceptualization
- the role of technology and innovation
- architectural design driver requirements
- Workshop 3 – identification of architectural design driver requirements
- techniques for stimulating innovation: brainstorming, TRIZ
- perspiration engineering: configuration items
- criteria for selecting configuration items
- design complexity trade-off
- relationship of CI definition to system integration
- Interactive exercise – a simple physical design
- Workshop 4 – physical conceptualization of solution
This module identifies the initial conceptualization of solution alternatives, and their transformation into an initial set of system elements (typically destined to become configuration items). The module examines briefly the role of knowledge and innovation, and some means of stimulating innovation, specifically brain-storming and TRIZ. First order and second order influences, on the transformation of each prospective broad concept into a candidate set of system elements, are then examined.
The interactive exercise of a simple physical design then continues, the aim being to both illustrate and exercise the basics of physical design with a practical example.
A major, team-based workshop is then conducted. The workshop aims to give delegates practical experience in exercising the basics of physical design. This workshop also uses the system which was the focus of previous workshops.
5. Functional Design
- functional analysis in design – how to do it
- functional analysis/architecture process
- item flow and control flow
- un-allocatable and allocatable functions
- pitfalls in defining functions
- common pitfalls in functional design
- interactive exercise – a simple functional design
- Workshop 5 – physical and functional design, part A
- Workshop 5 – physical and functional design, part B
- coupling, cohesion, connectivity
- FMEA/FMECA in design
- performance thread analysis
- relationship to object orientation
- allocation of functionality between hardware and software
- Fault Tree Analysis
- Event Tree Analysis
- behavior modeling languages
- other languages incorporating functional modeling: SysML, …
- software tools supporting functional and physical design
- pitfalls in functional design
This module of the course delves into the critical detail of logical design (model-based architecting/design), always with reference to the corresponding physical design – as must be the case in the real world of engineering. The focus is on the most widely used – functional – form of logical design.
An overall, effective methodology for maximizing the value of functional design is explained, as are the important concepts of coupling, cohesion and connectivity. These concepts influence the selection of logical design alternatives and their alternative physical implementations.
The interactive exercise of a simple functional design then continues, the aim being to both illustrate and exercise the basics of logical design with a practical example.
A major, team-based workshop is then conducted. The workshop aims to give delegates practical experience in exercising the basics of logical design. This workshop also uses the system which was the focus of previous workshops.
More elaborate forms of functional design involving behavior modeling are then considered, as is the use of simulation as a design/design verification tool. Representative software tools supporting physical and logical design are overviewed.
Failure analysis techniques are also addressed as a means to ensure a robust design. Some behavior modeling languages and software tools are identified before concluding with pitfalls in functional analysis.
6. State-Based Design
- state-based design – how to do it
- Workshop 6 – a simple state-based design
- relationship to object orientation
- SysML, and alternative languages incorporating state-based modeling
- software tools supporting state-based design
- pitfalls in state-based design
State-based logic is one of the forms of logical architecture identified in Module 3. This module looks at the use of statecharts as a technique for logical design that allows for concurrency of states, and makes provision for hierarchy of states. This is opposed to State Transition Diagrams (STDs) that are simply directed graphs, with nodes denoting states, and arrows denoting transitions, delivering flat, two-dimensional state diagrams which quickly becomes chaotic for complex, dynamic behavior.
7. Object-Process Methodology (OPM)
- background to OPM
- OPM description
- relationship to object orientation
- software tools supporting OPM
This module deals with Object-Process Methodology (OPM), a conceptual modeling language and methodology for capturing knowledge and designing systems, specified as ISO 19450. OPM is based on a minimal universal ontology of stateful objects and processes that transform them, and formally specifies the function, structure, and behavior of artificial and natural systems in a large variety of domains.
8. Design for Six-Sigma (DFSS)
- what is Six-Sigma?
- DMADV (DFSS)
- the DFSS toolset
This module addresses Six-Sigma, DMAIC (Define, Measure, Analyze, Improve, Control), DMADV (Define, Measure, Analyze, Design, Verify) as techniques for improving the quality of designs.
9. Return to Physical Design
- functional to physical allocation
- facilities, procedures, people, and other types of system element
- use of a specification tree
- system elements not designated as configuration items
- some common pitfalls in developing system physical architecture
- use of architectural design driver requirements
- adding the detail to the design
- design creates requirements – the duality of requirements and design
- interface engineering
- interface requirements specifications versus interface design descriptions/ICDs
- the OSI 7-Layer Model and similar in interface engineering
- relationship to system integration
- evolution of interfaces in systems having levels of structure
- some common pitfalls in interface engineering
- major artifacts created in design
In this module of the course, the focus becomes aspects of physical design beyond those directly related to logical design. A number of additional design techniques having application regardless of specific technologies are discussed.
10. Design Decision-Making and Optimization – Trade-Off Studies
- designing for feasibility
- designing for effectiveness: approach to design optimization
- the role of MOEs and goals
- the origin of a system effectiveness model
- designing for the company versus designing for the customer – handling conflict of interest
- using a system effectiveness model
- taking account of risk relating to goals
- taking account of risk relating to satisfaction of requirements
- event-based uncertainty
- risk aversion
- Workshop 7 – using a system effectiveness model
- cost/capability, return on investment and like concepts
- iterative optimization of design – an effective methodology
- other techniques – Quality Function Deployment
- software tools supporting design decision-making
- some common pitfalls in design decision-making
This module is conducted essentially as one substantial, interactive workshop. Initially, a System Effectiveness Model for the main workshop system is constructed. The model is then applied to evaluate alternative architectures from the previous design workshop. Reality is then increased, by adding consideration of uncertainty (giving rise to risk and opportunity), multiple stakeholders, and multiple uses. Time permitting, the concept of, and an effective approach to, event-based uncertainty is examined. This module concludes by emphasizing pitfalls and pointers that can make the difference between consistently sound decisions, and nonsense.
11. Engineering Specialty Integration
- what makes an engineering specialty special?
- common engineering specialties
- a generic approach to ESI
- organizational issues of ESI
- pitfalls, and specialty engineering examples
This module, delivered by presentation, looks (mainly) at the management techniques which may be applied to foster the effective integration of the relevant non-technology disciplines, e.g., safety, reliability, human factors, expandability, information security, etc., into the problem definition, into design, into verification and validation, and, as the end game, into the product.
12. Concurrent (Simultaneous) Engineering
- system of interest – enabling system relationships
- why concurrent (simultaneous) engineering
- organizational aspects of implementation
- process aspects of implementation
- pitfalls in implementation
This module introduces the concept of an Enabling System, as is a system that enables (makes possible) a stage or phase of the life cycle of the system of interest. It continues to introduce Concurrent Engineering as an approach to engineering that has the system of interest and its enabling systems developed concurrently, collaboratively and in balance to maximize value to the enterprise.
13. Summary and Key Points