Upcoming Courses

Register and pay 30 days prior to the course commencement date to receive a 10% early bird discount. Or register a group of 3+ for a 10% group discount. Available for corporate training worldwide.

Key Learning Objectives

At the conclusion of this course, participants are expected to have learned:

• the overall concepts which are characteristic of a systems approach to design;
• the overall process elements, and their relationships, that collectively constitute the process building blocks of design (verb);
• learn a structured approach to physical design, use logical solution to help get physical design right, evaluate solution alternatives (conduct trade-off studies) and optimize design in a structured way;
• learn in overview about the disciplines of reliability engineering, safety engineering, maintainability engineering and producibility (manufacturability) engineering;
• how to tailor the application of design principles and methods to different application scenarios; and
• how to design for reliability, safety, maintainability and producibility.

Training Method and Materials

The course makes extensive use of course workshops to put into practice the techniques covered in theory sessions.

The course is delivered using a mixture of formal presentation, informal discussion, and extensive workshops that exercise key aspects of a systems approach to design, using a single system throughout. The result is a high degree of learning, as evidenced by workshop work products, and the extensive commendations received from past participants.

Participants will be provided with:

• comprehensive course materials containing presentation material and supporting reading material;
• numerous supplementary descriptions, checklists, forms and charts which you can put to use immediately; and
• complimentary access to PPI’s evolving Systems Engineering Goldmine.

Some Key Questions

• What is architecture?
• Is architecture different to design?
• What is a systems approach to design and how is it relevant?
• What is the relevance of waterfall development, incremental development, evolutionary development, agile, spiral development, simultaneous/concurrent engineering?
• What is the timing relationship between logical and physical design?
• What is logical design, and what forms can it take?
• Why do we care about logical design?
• What is model-based architecting? Model-based design? Are model-based and model-driven different?
• What is object-oriented design and how does it relate?
• What languages and tools are applicable for model-based work?
• Where does FMEA figure?
• Is FMECA different to FMEA?
• What about FTA and ETA, where do they figure?
• Are model-based techniques limited to certain technologies?
• How can we be sure we have come up with the best design?
• Everywhere I turn there seems to be uncertainty. How can I make design decisions in the presence of such uncertainty?
• Is there a reliable and efficient way to optimize design?
• How do I design for reliability?
• How do I design for safety?
• How do I design for maintainability?
• How do I design for producibility?
• What are the Skills, Knowledge and Attitudes (SKAs) conducive to success in being a designer?

Who Should Attend This Course?

This design course is designed for personnel who perform or manage the development of small to large technology-based systems, products, capabilities, etc. The course will be of particular value to people with job titles such as:

• System Architect
• Enterprise Architect
• Design Engineer
• Systems Engineer
• Business Analyst
• Systems Analyst
• Software Systems Engineer
• Software Engineer
• Specialty Engineer – reliability, safety, maintainability, producibility
• Hardware Engineer
• Research Engineer
• Project Engineer
• Logistics Support Analysis Specialist
• Industrial Engineer
• Other engineering job titles
• R and D manager
• Engineering Manager.

0. Introduction – Architecture Design Within Systems Engineering (3 hours)

• 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.

1. Design-Related Principles of Engineering (2 hours)

• system views
• workshop 1 – design-related principles 

This module commences with 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.

This module then addresses key design principles starting with a whiteboard example and concluding with a workshop to establish an important foundation for what follows.

2. System Development Strategies (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 (1 hour)

• physical architecture (structural view) – basic concepts
• logical architecture – basic concepts
• logical architecture related to physical architecture
• reference architectures
• architecture patterns
• architecture models
• architecture frameworks
• useful forms of logical representation – functional, state-based, mathematical, hybrid, … with examples
• model-based design in practice – Model-Based Systems Engineering (MBSE)/Model-Based Architecting (MBA)/Model-Based Design (MBD)/ Model-Driven Analysis (MDA)/ Model-Driven Design (MDD)
• knowledge, skills and attitudes for architecting

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 (0.7 hour)

• the role of technology and innovation
• architectural design driver requirements
• workshop 3 – identification of architectural design driver requirements
• techniques for stimulating innovation: brainstorming, Teoriya Resheniya Izobretatelskikh Zadatch (TRIZ)
• perspiration engineering: configuration items
• criteria for selecting configuration items
• design complexity trade-off
• relationship of Configuration Item (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 participants 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 (6 hours)

• 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
  • Failure Modes and Effects Analysis (FMEA)/Failure Modes, Effects and Criticality Analysis (FMECA) in design
  • performance thread analysis
  • relationship to object orientation
  • allocation of functionality between hardware and software
• Fault Tree Analysis
• Event Tree Analysis
• behaviour modeling languages
• other languages incorporating functional modeling: Systems Modeling Language (SysML 1.x), …
• MBSE language comparison
• SysML2
• 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 participants 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 (2 hours)

• 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) (2 hours)

• background to OPM
• OPM description
• relationship to object orientation
• software tools supporting OPM

This module deals with OPM, a conceptual modeling language and methodology for capturing knowledge and designing systems, specified as International Standardisation Organisation (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 Decision-Making and Optimization – Trade-Off Studies (3 hours)

• designing for feasibility
• designing for effectiveness: approach to design optimization
  • the role of Measure of Effectiveness (MOE) 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.

9. Design For Six-Sigma (DFSS) (2 hours)

• what is Six-Sigma?
• Define, Measure, Analyze, Improve, Control (DMAIC)
• Define, Measure, Analyze, Design, Verify (DMADV)
• the DFSS toolset

This module addresses Six-Sigma, DMAIC, DMADV as techniques for improving the quality of designs.

10. Return to Physical Design (1 hour)

• 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/interface design drawings (ICDs)
• the Open Systems Interconnection (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
  
  • exercise – system architecting heuristics
• 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.

The focus of this module then becomes interface engineering. Aspects of interface engineering, and interface engineering management, are discussed. Although fairly short in duration, this content is critically important to minimization of problems when subsequently conducting system integration.

11. Engineering Specialty Integration (ESI) (0.3 hours)

• 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 (0.3 hours)

• 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. Reliability and Safety Engineering (6 hours)

• introduction to terminology
• measures of reliability
• probability theory related to reliability and safety
• Reliability Block Diagrams
• FMEA and FMECA
• workshop 8 – performing a basic define failure modes and effects analysis (DFMEA)
• Fault Tree Analysis and Event Tree Analysis
• common cause/common mode failures
• root cause analysis
• Markov analysis
• component failure and repair distributions
• Monte Carlo simulation and Latin Hypercube sampling
• reliability data and analysis
• verification of reliability
• measures of safety
• Hazard and Operability (HAZOP) studies
• safety assurance
• workshop 9 – performing a basic HAZOP Study

This module starts off by introducing the broad subject of Reliability, Availability, Maintainability, and Safety (RAMS). It then moves on to the subject of Fault Detection, Isolation, and Accommodation (FDIA) and uses some examples from the aviation industry to illustrate these concepts. It broadly addresses measures of reliability and associated probability theory before it looks at reliability block diagrams as a success-oriented view of system capability in the presences of failures. Failure Modes and Effect Analysis (FMEA) is addressed from a functional and piece-part perspective, as a systematic method of identifying the failure modes of a system. This is practiced in Workshop 8 with the execution of a simple Design FMEA.

Fault Tree and Event Tree Analysis is addressed as failure-oriented views of system capability. Common Cause failures are discussed together with three techniques to identify them. Root Cause Analysis (RCA) is further discussed as a means of dealing with the root causes of problems and not just their symptoms.

Redundancy can typically be exploited for safety-critical systems by operating in a number of possible degraded configurations or states. Markov Analysis is discussed as a means to predict the statistical likelihood of a system being in a particular state, the aim being to identify the degraded states that are still acceptably safe. Typical component failure and repair distributions are identified together with some statistical tests used in the analysis of reliability data. The topic of reliability is concluded with a discussion of the verification of reliability. Qualitative and quantitative measure of safety is discussed next, together with the Hazard and Operability Study (HAZOP), as a structured way of identifying potential hazards for a system. This is practiced in Workshop 9 with the execution of a basic HAZOP study. The use of Functional Hazard Assessments (FHAs) and Development Assurance Levels (DALs) are discussed in the use of a system safety assurance process before the module concludes with common pitfalls and pointers.

14. Maintainability Engineering (3.1 hours)

• measures of maintainability
• principles of designing for maintainability
• general techniques of designing for maintainability
• modules
• access and handling
• part selection
• verification of maintainability

The module identifies the measures of maintainability. It then discusses maintainability modeling techniques before moving on to general techniques of designing for maintainability. It concludes with maintainability demonstration – the evaluation and testing necessary to verify that the maintainability design criteria have been incorporated into the system design.

15. Producibility (Manufacturability) Engineering (3.1 hours)

• measures of producibility
• Design For Manufacture (DFM) vs. Design For Assembly (DFA)
• techniques of designing for manufacture
• design for three dimensional (3D) printing
• techniques of designing for assembly
• verification of producibility
• producibility risk analysis

The module addresses basic principles and design rules to ensure the manufacturability of product designs.

16. Summary and Key Points (0.5 hours)

• action plan

Q. Does the Architectural Design (AD5D) course cover concepts and methodology of TOGAF, DoDAF and related topics?

Yes, Architectural Frameworks are overviewed in PPI’s 5-day Architectural Design course (AD5D), but only briefly. The focus of the course is on efficient and successful architecting, not on organizing the information that is the product of the architecting.

TOGAF is actually a framework for organizing architecture and other information that is specific to IT systems. DODAF 2 is called an architectural framework, but it is really a structure for organizing project-related data, including some aspects of system architecture. In the view of PPI, the cost-effectiveness of DODAF 2 is yet to be demonstrated. PPI’s Architectural Design course focuses on the principles and methods of performing architectural (conceptual design) that generate architectures (conceptual designs). All of the information created in performing architectural design has a place in populating viewpoints defined within the various Architectural Frameworks, of which 55 are known to PPI. But duplication, ambiguity and illogicality are rife in the architectural frameworks, and typically, a large proportion of the content is not architecture. Expect at least 3 days of training to be needed to try to explain and defend any of the major architectural frameworks.

Q. Do you offer tailoring of this course?

Yes. All courses are tailored informally verbally in delivery by selecting, where possible, examples matched to the domains of interest to the class. We can also work with you to design a formally customized curriculum for the development of your people. We have done so for many client companies, and we would love to work with you to this end. We always suggest that a client takes the corresponding standard course prior to any customization. For systems engineering, this is because systems engineering is the problem-independent and solution technology-independent principles and supporting methods for the engineering of systems, based on systems thinking. So the objectives of customization need to be very clear and focused on adding further value. In practice, customization, if performed, usually becomes the replacement of examples and possibly the main workshop system with domain-specific equivalents. Substitution of the workshop system usually involves substantial redevelopment of courseware. Out of necessity, formal tailoring of courseware is performed on a fee basis.