Osh summit talk_v1.5
•Download as PPTX, PDF•
1 like•1,819 views
10-minute lightning talk delivered at 2010 Open Hardware Summit. The subject matter is emergent Systems Engineering methods from Open Source Hardware communities.
Recommended
Recommended
More Related Content
Viewers also liked
Similar to Osh summit talk_v1.5
Similar to Osh summit talk_v1.5 (20)
Recently uploaded
Recently uploaded (15)
Osh summit talk_v1.5
- 1. ARx: Almost Ready To Anything @thebarkleynow @ssayer New Methods in Systems Engineering Copyright © 2010, The MITRE Corporation. ALL RIGHTS RESERVED. Approved for unlimited distribution no. 10-3761.
- 2. Systems Engineering Systems Engineering (SE) – An interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and total life cycle balanced set of system, people, and process solutions that satisfy customer needs. ANSI/EIA-632-1999, 1999, “Processes for Engineering a System” ISO 15288, Nov. 2002, “A Guide for the Application of ISO/IEC 15288 System Life Cycle” IEEE 1220, 1998, “IEEE Standard for Application and Management of the Systems Engineering Process” IEEE 15288, 2004, “Systems and Software Engineering – System Life Cycle Processes” The International Council on Systems Engineering (INCOSE), 1990, http://www.incose.org
- 3. Systems Engineering Fundamentals, 2001, Defense Acquisition University
- 4. Systems Engineering Guidebook for ITS, v3.0 pp. 3.9.4, U.S. Department of Transportation
- 5. DoD Program System Engineering Management Plan (SEMP)
- 6. DOD Acquisition Lifecycle Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management System, Version 5.3.4, 15 June 2009. Defense Acquisition University, https://acc.dau.mil/ifc/
- 7. Kit Systems Almost Ready to Print (ARp) Almost Ready to Fly (ARf) Hardware Software Power Electrical Almost ready to drive (ARd) (frommacminter on flickr)
- 8. Open Source Systems Open Source Hardware (e.g. electrical components, sensors, microcontrollers) M A T U R I T Y Open Physical Components (e.g. brackets, mountings, enclosures) Open Source Software Open Power Supply
- 9. New Methods
- 11. SCRUM, 1995
- 13. Kit-style replicationOpen Hardware
- 14. The Power of Open Methods, not products make open models successful
- 15. Community Innovation 80% of innovations come from user communities because they’re innovating to benefit themselves, as opposed to companies who hope to innovate to sell products. The [community benefiting themselves] is natural and emergent, the [company hoping to innovate] is a guessing game. Democratizing Innovation, 2005. Eric Von Hippel, http://web.mit.edu/evhippel/www/books.htm
- 16. Observations on Traditional v. Open S.E.
- 17. The Good
- 18. The Bad
- 19. The Ugly
- 21. Open hardware technology gaps and capabilities
- 22. Evolution of open systems engineering
- 23. We have decided to document this as a public wiki
- 24. All are invited to contribute at ohroadmap.orgwww.ohroadmap.org jbarkley@mitre.org ssayer@mitre.org
Editor's Notes
- Jim Barkley & Sam Sayer work for The MITRE Corporation, which is a Systems Engineering company our backgrounds in CSCI so we basically have no idea what we’re doing in this hardware business, which hasn’t stopped us from being opinionated about where it’s headed20s
- Born out of 40s and 50s when weapons systems and aerospace grew beyond scope & tools of separate engineering disciplines Focus is on total system being engineered, such as a missile or an airplane Means a lot of focus is on integration of various engineering teams developing subsystems, team coordination, design & management issues Attempts to encompass a broad range of factors in system development, for instance cost/schedule/planning management, as well as engineering S.E. was always intended to be a practical, real-world approach The joke that goes around about systems engineering is that nobody actually knows what it is This actually not true. S.E. today is well-defined and has been codified in a number of standards, processes, documents and other artifacts Here are just a few juicy references for you of the many that exist Don’t have time to go too deep into S.E., but let’s show you a couple of function-following-forms
- Systems Engineering is notorious for these kinds of diagrams Heavyweight processes for controlling risk as you take a full system through it’s life from concept development all the way to sustainmentThis is just one small piece in the larger SE Fundamentals guidebook from DAU20s
- This is a “SEMP”, a Systems Engineering Management Plan, which is another diagram that shows up from time to time. There is even an eclipse plugin for Open Source Systems Engineering that tries to bring agile techniques to this particular process model. Again we can see phases like Concept of Operations, Requirements, Subsystem development, subsystem testing, system integration and verification, validation, O&M, etc.30s
- - Here’s an example from a real DoD program just to give you something a little more tacit This is only the 13 Elements in First Level of WBS A WBS is a way to define and group the engineering tasks which need to be done In this case, they are clearly driven by the S.E. processes underlying big system acquisition. And remember that S.E. was always intended to be a pragmatic, engineering approach to driving down risk and producing value in real, operational systems.25s
- This is how the government buys and builds new things it’s everyone’s favorite whipping boy I’ll grant that it is in many ways not particularly conducive to agile engineering, and it is one of many artifacts of a 50-year engagement with a fixed threat. However, we have to respect for what it is and the history behind it. When scrutinized, it is clear that this thing is intended to drive down risk in oh so many dimensions, and is driven by many underlying S.E. principles If you think this is unique to the USG, think again. How about other major system manufacturers, for instance from the auto industry? Toyota has one bad recall for gas pedal stickage in how many decades of good business? And as a result, the Toyota brand promise of quality is in serious jeopardy. In the case of the DOD the cost of failure can mean huge taxpayer burden and possibly risk lives In both cases, that amount of risk leads to this level of complexity. We have to respect those roots.90s
- What does Open Systems Engineering look like?Being born out of a hobbyist community, this has taken the form of kits. There is where we get the name of our talk, almost ready to fly print, some assembly required.
- What does agile systems engineering look like.Like agile software methods, we’re changing how hardware and systems are developed.Less focus on rigid process and more on rapid iteration
- In the early 90’s agile software processes started to emerge Following on the heels of Open Source software Open Hardware is emerging now Already seeing “agile systems engineering
- There is ongoing research into advancing traditional systems engineering to deal better with today’s adaptive, complex, and highly dynamic environments But another evolution of systems engineering is also coming from a more surprising place Open community models of development, which emerge organically But what makes open models so valuable? By the time an end user purchases a project for operational use (not research, development, or education) it matters little to them that it is open hardware, software, or architecture. As system developers, what’s valuable about open models is that it allows us to develop better products faster Therefore, it’s not the end product but rather the path through which that product is achieved What is it about these methods of development that allows open projects to rapidly ascend this disruptive curve?30s
- - A big part of it, is the ability to innovate.This is a paraphrase from Eric Von Hippel on community innovation. What it says is that user communities innovate better because they know what they want. We hear this all the time at MITRE in the software world. - But what’s so great about innovation? Maybe that coffee cup factory is a better investment…30s
- - A big part of it, is the ability to innovate.This is a paraphrase from Eric Von Hippel on community innovation. What it says is that user communities innovate better because they know what they want. We hear this all the time at MITRE in the software world. - But what’s so great about innovation? Maybe that coffee cup factory is a better investment…30s
- We’re really good at systems requirements analysis, design and development.Our strengths draw from being our own end users. We know what we want, and we have a passion for building it and making it better because it makes our own lives better.
- Some areas for improvement.Operations & Maintenance – We’re struggling to support the project in the post-define phase. While we’re really good at developing & designing open systems, we need to improve the phases that follow. System Integration is responsibility of the end user, not part of design. “Heroes” integrate separate systems in interesting ways.
- RMA = Reliability, Maintainability, and AvailabilityThese are things that are not easy to do, but also not easy to win at. One small mistake here can cause large problems, as Jim mentioned about Toyota. Currently we’re utilizing an “opt-in” model, we acknowledge these shortcomings and are awarRMA and Safety Engineering are considered whole fields of technical specialty in the Systems Engineering ecosystem.