Week 7 - Systems Engineering and Analysis

1. Week 7 - Systems Engineering and Analysis Buede Chapter 10 – Interface Design Chapter 11 – Integration and Qualification (Side order of Rapid Development)

2. Interfaces • A connection for ‘hooking together’ system components – external or internal. • Have a logical and physical component responsible for carrying information or electromechanical energy from one component to another. • Must identify interfaces, evaluate options, and allocate inputs/outputs to them.

3. Approaches to Interface Considerations • Buede’s Ch. 10 – somewhat limited in scope to computer/software interfaces. • (Good for us software types!) • Wasson – detailed • Schindel • Some tips, added to these slides • Rapid Prototyping

4. Wasson on Interfaces • Interfaces are all about how systems and subsystems interact with each other and their operating environment. • Interface Purposes • Physically link or bind two or more system elements • Adapt one or more incompatible system elements • Buffer the effects of incompatible system elements • Leverage human capabilities • Restrain a system element and its usage

5. Broad View of Interfacing • Wide variety of ‘interfaces’ in all systems and products. • Software • Communication • Electrical • Mechanical • Optical • Acoustical • Chemical • Biological • Etc…

6. Logical Direct or indirect association between two entities Who communicates What scenarios When to communicate Physical How communication happens ‘Specialized’ interfaces Logical vs. Physical

7. Standardized vs Dedicated • Standardized – standard, modular, interchangeable interfaces – complying with a ‘standard’ like RS-232, USB, Ethernet, etc. • Dedicated – Unique, dedicated interfaces – often limiting compatibility with other systems

8. Wasson Interface Thoughts • Consider interactions between system and environment. • Often focus on a few, not all interactions • Environmental effects are natural, induced, and human-made.

9. Where are the Interfaces? At: Inputs Controls Outputs

10. Where are the Interfaces ? At: Inputs Controls Outputs

11. Define Interface Requirements • Identify the Items to Be Transported by the Interface • Define the Operational Concept • Bound the Problem with an External Systems Diagram • Define the Objectives Hierarchy • Write the Requirements • Select a High-Level Interface Architecture of Interface • Identify Several Candidate Architectures • Define Trial Interfaces for Each Candidate • Evaluate Alternatives against Requirements • Choose High-Level Interface Architecture • Develop Functional Architecture of Interface • Specify Functional Decomposition • Add Inputs and Outputs • Add Fault Detection and Recovery Functions • Develop Physical Architecture of Interface • Identify Candidates based upon High-Level Architecture • Eliminate Infeasible Candidates • Develop Operational Architecture of Interface • Allocate Functions to Components of the Interface • Analyze Behavior and Performance of Alternatives • Select Alternative • Document Design and Obtain Approval • Add Functions to Components Connected to Interface as Needed Interface Design Process The same SE process !! Figure 10.7

12. Benefits of Standards • Interchangeability - ability to interchange components with different performance and cost characteristics • Interoperability - the system can now operate with a wider variety of external systems, systems that have also adopted the same conventions • Portability - systems can be moved and operate on other systems • Reduced cost and risk for equivalent performance • Increased life cycle is possible when long-lived standards are adopted

13. Schindel Interface Thoughts • List of all I/O that pass through it • List of functions or behaviors at the interface • Association with a system that owns the interface • SOA – technologies or systems that support the interface • An interface does not reside ‘between’ two systems.

14. Schindel Interface Thoughts • List of all I/O that pass through it • List of functions or behaviors at the interface • Association with a system that owns the interface • SOA – technologies or systems that support the interface • An interface does not reside ‘between’ two systems. Additional Thoughts: All I-C-O to a function must be associated with an interface. In addition to the function/behavior, also list the physical characteristics.

15. Interface Examples

16. Interface Template

17. Defining and Managing Interfaces • IRS – Interface Requirements Specification (not always necessary) • ICWG – Interface Control Working Group • ICD – Interface Control Document (Hdwe) • IDD – Interface Design Description (Sftwe)

18. Schindel Interface Thoughts • List of all I/O that pass through it • List of functions or behaviors at the interface • Association with a system that owns the interface • SOA – technologies or systems that support the interface • An interface does not reside ‘between’ two systems.

19. Key Interface Attributes

20. Interface Definition and Control Challenges – Pg 519

21. Oasis Example What is Good ? What is Bad ?

22. Context of ‘Rapid Development’ • ‘For us – “Agile” and “Lean” • Designing Products in Half the Time’, Reinertsen • Keys – • Functional decomposition and allocation • Modularity – more rapid development, but more modules, more interfaces. • Performance margin in each module. • More margin, fewer changes, but higher cost.

23. ‘Rapid Development’-2 • Keys – • Interface Design • Link modules and functions together. • Stable, robust, standard, simple. • Robust – performance, electrically, mechanically, environmentally, etc. • Standard – faster, cheaper.

24. ‘Rapid Development’-3 • Goal – • Design ‘Architectures’ fast, early. • Modular design with known interfaces. • Flow down requirements to interfaces. • Then - Work on modules independently, concurrently.

25. ‘Rapid Development’-4 • Standard Interface- • Need ‘interface’ to carry 110 VAC power from a power source to electrical system under development. • Standard interface – buy at hardware store (COTS) (commercial off the shelf). • Custom interface – design, develop, manufacture, safety/life testing, etc.

26. Interface Thoughts • An interface is a property of a system component, it does not reside between two systems. – Bill Schindel • The distinction between : • The Interface, • The Physical Component, • The ‘Standard’ involved, if any. A car battery is a standard interface to provide electrical power to the car….(?)

27. A Car Battery • What are the external systems ? • What are the inputs and outputs ? • An interface at each one !

28. Interface Implications • More interfaces – more modular, upgradeable, testable, but more expense. • But, systems tend to fail at an interface – solder joint, connector, bolted joint, data transfer between modules, etc. • May ‘over-design’ each module

29. The ATM Functional Architecture • Define the Interface at each I-C-O. • Define the logical/functional behavior. • Define the physical and standard/custom instantiations.

30. Class Exercise • Consider the following systems. Further consider the typical subsystems which make them up and identify interfaces necessary to support the system. • Use the Interface Template as a guide to describe the interface behavior and characteristics. Note that several signals may pass through the same interface. • Elevator System (*) • Desktop PC • Machine Tool • This Classroom • Digital Camera • Your Car • Your Project System …..

31. Interface Template

32. Week 7 - Systems Engineering and Analysis Buede Chapter 11 – Verification/Validation, Integration and Qualification

33. Definitions • Integration is the process of assembling the system from its components, which must be assembled from their configuration items (CIs) • Qualification is the process of verifying and validating the system design and then obtaining the stakeholders’ acceptance of the design. • Qualification = ‘Testing’. • Verification is the determination that the system was built right (more of a process focus) • Validation determines that the right system was built (more of a product focus)

34. Verification, Validation and Acceptance 1 6 2 5 4 3 Verification = Built Right Validation = Right System Acceptance = Stakeholder OK Figure 11.1

35. Verification/Validation/Acceptance • Do not happen sequentially • Do not only happen late in the SE process

36. Major Integration Functions for Component Integration The Textbook Approach is ‘Bottom Up’ Figure 11.4

37. Approaches to Integration • Top Down • Bottom Up (*) • Big Bang

38. Top Down Integration Integration begins with a major or top-level module. All modules called from the top-level module are simulated by “stubs” (shell or model replica). Once the top-level module is qualified, actual modules replace the stubs until the entire system has been qualified. This is most useful for systems using large amounts of COTS components. Phase Integration: Integration is done from the top down to the lowest level; one peel of the onion at a time. Incremental Integration: Integration is done for a specific module from top to bottom; one slice of the system at a time. Advantage • Early demonstration of the system is allowed. • Representation of the test cases is easier. • More productive if major flaws occur toward the top of system. Disadvantage • Stubs have to be developed. • Representation of test cases in the stubs may be difficult. • Observation of test output may be artificial and difficult. • This requires a hierarchical system architecture. Table 11.1

39. Bottom-up Integration Integration begins with the elementary pieces (or CIs) of the system. After each CI is tested, components comprising multiple CIs are tested. This process continues until the entire system is assembled and tested. This is the traditional systems engineering integration approach. Phase Integration: At any point in the integration, all of the subsystems are at the same stage of integration testing. Incremental Integration: proceeds one slice of the system at a time. Advantage • It is easier to detect flaws in the tiniest pieces of the system. • Test conditions are easier to create. • Observation of the test results is easier. Disadvantage • “Scaffold” systems must be produced to support pieces as they are integrated. • System’s control structure cannot be tested until the end. • Major errors in the system design are typically not caught until the end. • System does not exist until the last integration test is completed. • This requires a hierarchical system architecture. Table 11.1

40. Big Bang Integration Untested CIs are assembled and the combination is tested. This is a commonly used and unsuccessful approach. Advantage • Immediate feedback on the status of system elements is provided. • Little or no pretest planning is required. • Little or no training is required. Disadvantage • Source of errors is difficult to trace. • Many errors are never detected. • Test it until it ‘works’ then stop. • Errors found by customers Table 11.1

41. Bottom-Up Integration of RC Car

42. Exercise: Discussion of Examples • How did they do integration on the Denver Airport project. • Even when large amounts of time/money are spent on integration/qualification, how are mistakes still made – Genesis and other space vehicle failures ? • Why is the Big Bang approach so popular or often used? • What integration approach would you recommend for your project ?

43. Qualification Planning During Design • The design of the qualification system is not only important in terms of finding and defining faults and errors but also in guiding designers to preclude them from introducing faults in the first place. Buede

44. Qualification – The ‘Readers Digest’ Edition • If you can't test it, don't build it. • If you don't test it, rip it out. • Boris Beizer, Second edition, chapter 13, section 3.2.5. , "Software testing techniques" by Boris Beizer , ISBN: 0442206720

45. One Way to Look at it Qualify ATM Machine Develop a Systems Model for this Function

46. Circuit Board Testing Qualification an Afterthought

47. Circuit Board Testing Qualification planned and designed

48. Failure Definitions • Failure: deviation in behavior between the system and its requirements. Since the system does not maintain a copy of its requirements, a failure is not observable by the system. • Error: a subset of the system state, which may lead to a failure. The system can monitor its own state, so errors are observable in principle. Failures are inferred when errors are observed. Since a system is usually not able to monitor its entire state continuously, not all errors are observable. As a result, not all failures are going to be detected (inferred). • Fault: defects (bugs) in the system that can cause an error. Faults can be permanent (e.g., a failure of system component that requires replacement) or temporary due to either an internal malfunction or external transient. Temporary faults may not cause a sufficiently noticeable error or may cause a permanent fault in addition to a temporary error.

49. Levels of Bug/Fault Severity and Consequences • Mild • Moderate • Annoying • Disturbing • Serious • Very Serious • Extreme • Intolerable • Catastrophic • Infectious

50. Boris Beizer’s 3 Laws of Software Testing • First Law: The Pesticide Paradox – Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffective. • Second Law: The Complexity Barrier – Software complexity (and therefore that of bugs) grows to the limits of our ability to manage that complexity. • Test developers are no ‘smarter’ than code developers. Errors on both sides. • Third Law – Code migrates to data. • More and more of the control and processing functions are stored in tables. Control tables having hidden programming languages, generalized packages with parametric data to the code, etc. • Because of this law there is increasing awareness that bugs in code are only half the battle and that data problems should be given equal attention.