Systems Engineering Lecture 7 Systems Architecting Dr Msury

Systems Engineering Lecture 7 Systems Architecting Dr. Msury Mahunnah course website: https: //mahunnah. wordpress. com/

Agenda • • Objectives Analysis of architecture A useful tool Synthesis of architecture

Learning Objectives 0) Be able to apply the principles, processes and tools of system architecting to structure and lead the early, conceptual PDP phase 1) Discuss systems, systems thinking, products, the PDP and the role of the architect 2) Critique and create architecture, and deliver the deliverables 3) Drive ambiguity out of the upstream process 4) Create the concept 5) Manage the evolution of complexity 6) Critically evaluate current modes of architecture 7) Develop the principles of architecting This is a course in how to think, not what to think

Process for Critical Thinking • Opportunity, challenge, or reference example identified • Thinker develops an approach option • Thinker identifies other options, then analyzes and criticizes the options vs. each other and the “developed” approach • Synthesized, context-appropriate “best” option is defined

The Role of the Architect • Defines the boundaries, goals, and functions • Creates the Concept • Allocates functionality and defines interfaces and abstractions The architect is not a generalist, but a specialist in simplifying complexity, resolving ambiguity and focusing creativity

Four Basic Tensions in Product/System Development Benefit Schedule Risk Cost Value is Benefit at Cost

The Architect Creates Good Architecture • • Satisfies customer needs Incorporates appropriate technology Meets strategic business goals Meets or exceeds present and future regulations H Is operable, maintainable, sustainable, reliable H Can be evolved/modified as appropriate n Can be designed and implemented by envisioned team n Can be implemented with existing/planned capabilities AND IS ELEGANT

Deliverables of the Architect • • • A clear, complete, consistent and attainable (with 80%90%confidence) set of goals (with emphasis on functional goals) A functional description of the system, with at least two layers of decomposition A concept for the system A design for the form of the system, with at least two layers of decomposition A notion of the timing, operator attributes, and the implementation and operation plans A document or process which ensures functional decomposition is followed, and the form at interfaces is controlled

Architecture - 6 Views Principles Roles & Frameworks Cases Definitions Methods & Tools Themes

Analysis of Architecture • Form, function and concept - the architecture • Upstream influences • Downstream influences

A Definition • Architecture • Consists of: – Function – Related by Concept – To Form Function – The embodiment of concept, and the allocation of physical/informational function (process) to elements of form (objects) and definition of structural interfaces among the objects Form Concept

Architecture – Form Suspension bridge Cable-stayed bridge

Product Attribute - Function • Function is the activity, operations, transformations that create or contribute to performance • Function is a system attribute, created by the architect • Function is associated with form, and emerges as form is assembled • Function can stated in solution neutral form, as a verb plus noun, and with a limited syntax • Externally delivered function is linked to value of a product

Function is Associate with Form • Change voltage proportional to current • Change voltage proportional to charge • React translation forces • Carry moment and shear

Concept - the Mapping of Form to Function • • • A system vision which maps form to function and embodies working principles Is in solution-specific vocabulary - it is the solution Is created by the architect Must allow for the execution of all functions Specifies the vector of design parameters, which, when selected, will establish the design Is an abstraction of form, or form is a specification of concept Form Function • Concept

Dominant Upstream Influence on Architecture Regulation Corporate, Marketing Strategy Competitive Environment Downstream Strategies, Competence Technology Need Goals Function Customers Architecture Form Concept

Product Attribute - Need • • • Need is defined as: – an overall desire or want – a necessity – a wish for something which is lacking Can also include opportunities to fill unexpressed needs Exists in the mind of the beneficiary (outside the enterprise) Expressed often in fuzzy or general (i. e. ambiguous) terms Is interpreted (in part) by the architect

Product Attribute - Goals • Goal is defined as – what it accomplishes, its performance – what the designer hopes to achieve or obtain • Expressed in the precise terms of Product Development • Will include goals derived from user Needs (goals from beneficiaries) i. e. the external functional goals • Will also include goals from corporate strategy, regulations, competitive analysis, etc. • Embodied in a statement of goals (requirements ? ) • Is defined (in part) by the architect • Exist within, and under the control of the enterprise, and are traded against other attributes

Framework for Downstream Influences Implementation Function Architecture Form Operations Concept Operator (training, Operational etc. ) sequence and dynamic behavior Operational cost Evolution Design

Product Attribute - Timing • • • When the system operates, the time sequence of events Has two important aspects – Operational sequence – Dynamic behavior Operations sequence is the total set of steps or processes that the system undergoes, inclusive of the primary process for which it is intended – Including set up, take down, stand alone, contingency and emergency operations • Dynamic behavior is the detailed timing of steps, their sequence, start time, duration, overlap, etc.

Overall Operational Sequence Store Waiting in storage Retrieving, connecting, powering-up, setting up, initializing Get ready Loading, preparing OPERATING Process only ops. Executing Primary Process Get set Contingency ops. Emergency ops. Go Archiving, unloading Terminating, disconnecting, depowering, storing Inspecting, repairing, calibrating, updating, maintaining Get unset Get unready Fix

Product Attribute - Operator • • • Who will use/execute the system Necessary for products with human agents/operators/supervisors [which ones don’t? ] – most important for human-in-loop (e. g. aircraft, bicycle) – important for direct human operation (e. g. lathe, wheelchair, calculator) – for other products, can be considered part of interface/constraints (e. g. human factors design, industrial design) Because of the unique issues of human performance and safety, it is useful to keep separate as an additional attribute

Product Attribute - Operations Cost • • • Operations Cost is a product attribute How much it will cost to operate the system This is the recurring operational related costs – Operator and other personnel – Training – Maintenance and (nominal) upgrades – Consumables – Indirect operating costs (insurance, etc. )

Holistic Framework for Attributes of the Product and its Operations global why global what global global where when who how much how the the things does system elements occur them are is built accomplishes acts need opportunity does it cost function form timing operator cost performance process structure dynamics user expense goals

Other Downstream Processes • • The system must be designed, so it must be architected in such a way that design can proceed smoothly and efficiently The system must be implemented, so it must be architected for manufacturability, coding, integration, test, and verification The system may evolve and be updated, so it must be architected with a view towards these changes Evolution is really just a recursive pass through conception, design and implementation Each has its own who, what, where, when, . . .

Qualitative PDP - CDIO Designing Conceiving Design Goals Design Tools Product Function Customer Corporate Societal Needs Product Goal NRE Costs Design Schedule Process Methods Design Team Operating Costs Product Timing Product Form Product Operator Operating Impl. Goals Implementing Impl. Team Impl. Tools Process Flow Impl. Schedule Impl. Costs

Generic PDP Conceive Design Mission Conceptual Design l l l Business l Strategy l Functional l Strategy l Customer l Needs l Competitors l Program l plan Business l case Goals Function Concepts Regulation Technology Platform plan Supplier plan Architecture Commitment Envision Preliminary Design l l l Requirements l definition Model l development Requirements l flowdown Detail decomposition l Interface control Implement Detailed Design elaboration Goal verification Failure & contingency analysis Validated design Element Creation l l l Integration, System Test Sourcing Implementation ramp-up Element implementation Element testing Element refinement l l l l Design Operate Product integration Product testing System testing Refinement Certification Market positioning Delivery Develop Life Cycle Evolution Support l l l l Sales, Distribution Operations l Logistics Customer l support Maintenance, repair, overhaul Upgrades Product improvement Family expansion Retirement Deploy

A Tool - Object Process Modeling • • • Object: that which has the potential of stable, unconditional existence for some positive duration of time. Objects have states. Form is the sum of objects Process: the pattern of transformation applied to one or more objects. Processes change states. Function emerges from processes All links between objects and processes have precise semantics Objects Processes

Process and its Links • • • A process is associated with a verb and stateless There a family of about 5 types of links from process to object A process changes the states of its operand(s) through input and output links Input link • Output link Transporting changes person from here to there.

Summary Object. Process Links • P affects O (affectee) • P yields O (Resultee) • P consumes O (Consumee) • P changes O (from state A to B). • P is handled by O (agent) • P requires O (Instrument)

Emergence • • • A process can be zoomed into sub-processes A process emerges from sub-processes The process and sub-processes are not linked in any explicit manner, as the object decomposes into parts Emergence is a powerful feature of systems - parts and sub-processes can come together to cause a process to emerge Emergence sometimes yields the anticipated processes, sometimes does not yield the anticipated process and sometimes unanticipated processes

Synthesis of Products • Parallel processes: Architecture & Business Case • Tracing value to architecture • Ambiguity, creativity and complexity • Conclusions

Parallel Cycles • The parallel cycles end when: - The technical architecture “closes” - The business case “closes” • The outputs are products with value to customer and profits with value to share holder, while providing appropriate value to society and workforce.

Intent • • • An Intent is – What the purpose is – What someone hopes to achieve or obtain Is always defined by someone Useful to create a special symbol for this information object supposed to remind you of an arrow - where you are going Intent

• • Function - A Formal Definition Previous Definition: the …transformation…that contribute to performance…the actions…for which a thing exists Function is intent plus process Intent Process

Value - Formal Definitions Value is delivered when the primary external process(es) acts on the operand in such a way that the needs of the beneficiary are satisfied at a desirable cost. Operand Beneficiary Value Delivery Has Needs Interpreting & Incorporating Delivering Primary Process Intent on process Value Identification Value Proposition Product Object Value: “how various stakeholders find particular worth, utility, benefit, or reward in exchange for their respective contributions to the enterprise” Murman, et al. LEV p 178

Product Systems and Value • • • Products include Goods, which are objects which implicitly execute a process Products include Services, which are processes enabled by implicit objects In both cases, the value to the primary beneficiary is in the process, not the object Products Goods Services Implicit Process Implicit Objects

Whole Product System • The whole system is the array of objects necessary to deliver the externally delivered process to the operand(s).

Value to Intent • • • Start by examining the operand associated with value Next identify the attribute of the operand whose change is associated with value Next define the transformation of the attribute associated with value, in solution neutral form This will reduce ambiguity and lead you to a value focused, solution neutral statement of intent on process

Concept • • • Concept: a system vision, which embodies working principles, a mapping from function to form Choose from among the system operating processing that specialize to the desired solution neutral, value related process Specialize the related generic concept to the product form This is the exercise of creativity Five primary functions. Mc. Gee, de. Weck Concept

Capturing Intent • • • Once the system is modeled or built, the “attribute transforming” process and “concept” object vanish The “attribute transforming” can be captured as an intent object The concept usually remains implicit, represented by the operating process and concept specialization

Decomposition of Function and Form • • Identify form of the whole product system Zoom the processes of function Decompose the form of the product object Establish the object process links

Form and Function - Cooler • • The whole product includes the ice, food, supporting surface, heat load, light and operator Chilling zooms to the stated processes (using process precedence framework) Cooler decomposes to box and top Map objects to processes to determine object-process architecture Establishing the complexity of the object-process architecture

Structure of Form - Cooler • Examine the interactions implied by the decomposition of form Establishing the complexity of the object-object architecture

Form and Function - Refrigerator • • More one to one correspondence of objects and processes Note the whole product elements suppressed: – Food – Support structure – Heat load – Operator

Structure of Form - Refrigerator Considerably more object - object complexity

So Why Refrigerators and not Coolers? • • Refrigerators have significantly more complexity than coolers Refrigerators have more functions, performance and robustness than coolers. Is a principle lurking here? Principle: underlying and long enduring fundamentals that are always (or almost always) valid.

A Principle Robust Functionality Drives Essential Complexity • • Essential complexity is that which is essential to deliver functionality before gratuitous complexity slips in Functionality drives complexity in any given concept But “Functionality” is often defined as a surrogate for a much broader set of functions which the product will actually be use for. Therefore, it is the (often implicit) robust functionality which drives essential complexity

Conclusions • • • Architecture requires consideration of form and function, related through concept Value derives from function Starting with the operand, its transformation identifies concepts which deliver value Concepts elaborate into architectures which have form-function and structural complexity Essential complexity is accepted to deliver robust functionality