Systems Engineering - a smarter way
•
6 likes•5,390 views
A brief introduction to emerging trends in systems engineering and how collaborative tools are make engineers more productive.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Systems Engineering - a smarter way
Similar to Systems Engineering - a smarter way (20)
Recently uploaded
Recently uploaded (20)
Systems Engineering - a smarter way
- 1. Smarter Systems Engineering Pittsburgh INCOSE Mark Borowski Client Technical Professional and Enablement Executive IBM Software, Rational
- 2. What was Next… is NOW! MINORITY STAR IRON MAN REPORT TREK Exoskeleton Vehicle-to-vehicle Sensory Robotic Suit Communication Substitution Device 2 © 2012 IBM Corporation
- 3. Today’s innovations are enabled by software …this shift is changing the world in which we live Global Networked Bandwidth Integration Technologies Explosion 3 © 2012 IBM Corporation
- 4. In many ways, the world is becoming smaller Enabling new levels of integration and collaboration Global Networked Bandwidth Integration Technologies Explosion 4 © 2012 IBM Corporation
- 5. In other ways, the world is also becoming smarter Enabling new levels of customization, functionality and client value INTELLIGENT INSTRUMENTED INTERCONNECTED 5 © 2012 IBM Corporation
- 6. Smarter products are the building blocks of today’s smarter planet 6 © 2012 IBM Corporation
- 7. Yet with this new reality comes challenges and opportunities for systems engineers BEST-IN-CLASS “I need to better understand my design alternatives Improve ability to predict 88% earlier in the development process” system behavior “I need a level of traceability that allows me 39% Link requirements to to verify what was specified was delivered” specific test cases “I need to manage change across mechanical, 1 of 4 Involve multiple electrical, and software engineering” engineering disciplines in design reviews Aberdeen Group: “System Design: Get it Right the First Time”, August, 2011 7 © 2012 IBM Corporation
- 8. Added Capability Creates Complexity Many notable system failures have been failures in subsystem interfaces, requirements fidelity and systems engineering – Systems have become more complex through integration • E.g. automobiles with multiple ECUs are more like a network of general purpose computers with large network software – Projects with 700-2000 requirements cannot be held in mind at full detail • Models with varied levels of abstraction must be used – Managing change and understanding impact of change is a $$$ million problem • Requirements models and automated tools must be used to be effective Interestingly, these are failures of knowledge and communication, not of engineering. 8 8 © 2012 IBM Corporation
- 9. “Test-in Quality” is a Non-Starter Bugs and flaws are often expected to be caught and fixed during testing phase – Follows the waterfall, but often stalls testing (or worse, overloads the Test Team by making them forensic developers) Goal is to move to “Design-in Quality” – Quality checks performed at each development iteration – Testing directly linked to all development process stages – Stakeholders aligned through linked work items 9 © 2012 IBM Corporation
- 10. And with this new reality also comes challenges and opportunities for software engineers “I need to know what I need to develop — 1 of 2 Challenged with scope nothing more, nothing less” creep and changing requirements “I need to show that I am compliant with 2x Need for standards the standards required by my industry” compliance doubled since 2009 “I need to know when changes are made to the 45% Use hardware/software hardware to avoid unpleasant ‘surprises’ later” dependency management 10 © 2012 IBM Corporation
- 11. Today’s reality: for integrated device and software of systems development Device software designs completed 66% over budget EMF 2003 Projects canceled due to 24% unrecoverable slip in schedule EMF 2003 Produced devices do not meet 33% XX% performance or functionality requirements EMF 2003 Software content in devices is 2x doubling every two years IDC 2002 11 11 © 2012 IBM Corporation
- 12. New and enhanced solutions for systems and software engineers Design, deliver, Accelerate development Access and manage smarter with industry specific a growing products from planning complex software and extensive to development through and systems business partner product support development solution ecosystem 12 © 2012 IBM Corporation
- 13. System-of-Systems modeling integrates software, hardware, people and Software information into a cohesive, comprehensive model Hardware A “system” regardless of its size or function is made up of some combination of these four elements. Workers A large, complex system can be modeled as a system Information of systems. This kind of model has great flexibility and can apply to machines, devices, business organizations or enterprises. Software Software Software Software Hardware Hardware Hardware Hardware Workers Workers Workers Workers Information Information Information Information 13 © 2012 IBM Corporation
- 14. Advanced Requirements Management Derivation Requirements are no longer “one kind of thing” Recognize levels and types and y ili baecar T their relationships Implement “live” traceability between all kinds of requirements, t including architecture and design Link requirements to design, implementation, verification and validation, user training, etc. 14 14 © 2012 IBM Corporation
- 15. The Changing Role of Requirements Text requirements give rise to models which elaborate and elucidate Models give rise to additional text requirements which specify and constrain Text Text and models are useful at all Models levels of system abstraction Capture rationale and thinking at each level to differentiate requirements from design choices 15 15 © 2012 IBM Corporation
- 16. What Makes a Model a Model? The Dumb Way The Smart(er) Way =-A11*4*(1-B11)+4*C11 =NORMDIST(A11,0,1, Smarter or Dumber? FALSE) =100+3*50+2*3*70+3*3*40+4*3*100 Requirements Trade Studies +5*3*125 Flowdown / Allocation Designs Component The relationships are baked-in Specifications TPMs Optimized for change 16 © 2012 IBM Corporation
- 17. Model-Driven System Development models a system-of-systems in four recursive stages Context describes the system and the Context people and systems who interact with it (actors). Usage describes how the actors use the Usage system is used to produce the results and purposes of the system. Realization Realization describes how each usage is and Joint Realization accomplished by a collaboration of system elements using various viewpoints. Execution Execution enables demonstration and proof of the model through execution. 17 © 2012 IBM Corporation
- 18. Example: GPS-Guided Travel GPS Features – Set destination (address, point of interest, etc.) – Navigate to destination – Retrace route – Get back on track GPS Usage Model – Find me a gas station on my way – What’s the nearest McDonald’s? – Is there a Hilton Hotel I can reach in about 5 hours? – Let’s avoid freeways 18 18 © 2012 IBM Corporation
- 19. V-Diagram of Systems Engineering Work Shows progressive decomposition of requirements/ design (left side) Shows progressive integration and verification of subsystems (right side) Source: Systems Engineering for Intelligent Transportation Systems Washington State Department of Transportation, December 30, 2005 19 02/12/13 Template Documentation 19 © 2012 IBM Corporation
- 20. Time progression in V Diagram Source: INCOSE Handbook, p3.6 02/12/13 Template Documentation 20 © 2012 IBM Corporation
- 21. Source: INCOSE Handbook, p3.8 Template Documentation 21 © 2012 IBM Corporation
- 22. Integrated System/Embedded Software Development Design iterations in the “V” development lifecycle 22 22 © 2012 IBM Corporation
- 23. Technical Work Management: Collaboration and Communication Communication among teams facilitated by Systems Engineering Reduce wasted time / error associated with misunderstandings and incomplete mental pictures Why are small teams so effective? of system requirements Build common, shared work products among cross-functional teams – Model-based – Shared repositories (requirements, change requests, issues, defects, configurations) Coordinated, automated workflow tied to shared work products – Avoid email exchange of work products, multiple versions, confusion Build on integrated tooling infrastructure – Limitations of point-to-point integration – Jazz Platform and OSLC Vision 23 23 © 2012 IBM Corporation
- 24. Technical Work Management: Enabling Effective Collaboration (Why better than email?) Capture customer requests & market Manage driven enhancements Execute Portfolio & Tests Product Testing Eco-system Priorities Collaboration, Process, Workflow Integrated Capture & Change Management manage requirements Configuration Management Develop - Model-Driven Collaborate across • System Engineering Development Disciplines • Software Engineering Software • Electrical Engineering • Mechanical Engineering Electrical Shared Repository Mechanical 24 © 2012 IBM Corporation
- 25. Collaboration in Action Team Awareness • Shows team members and their online status • Shows what they are working on Change Awareness • Automatically links to changes if mentioned in chat • Drag and drop any work item or query into chat 25 25 © 2012 IBM Corporation
- 26. Enabling Collaboration with Models Collaborate with stakeholders with View design commenting over web Browse Mark-up diagrams to design elaborate comments information 26 © 2012 IBM Corporation
- 27. Systems Engineering Traditionally Floats on a Sea of Documentation Missing Format information inconsistency Document-centric approach results in information dead- ends No access to Document source disparate products Changes make application documents obsolete before they are Engineers Overwhelmed engineers & approved working off misinformed old versions of specs managers Documents remain necessary for Document contractual Documentation preparation for not up-to-date reviews management and agreement 27 27 © 2012 IBM Corporation
- 28. Automated Document Production Treat documents as reports of live information Facilitate re-use and consistency Clients Source Apps Publishing Composite Documents System requirements DOORS Reqts Templates models test() Models tes t() test() actor XML Sources Data other sources REST Sources 28 28 © 2012 IBM Corporation
- 29. Closed Loop Governance: Measure and Improve Performance Measurement (IBM Rational Insight) Business Level Value Metrics Business Objectives feedback e.g., ROI, ROA for SSD 0% 100% Operational Level Operational Effectiveness Metrics Feedback Operational Objectives feedback e.g., Time to market, productivity 0% 100% Practice Practice Level Process Definition / Practices feedback Adoption/Maturity Practice Rational Method Composer Subjective Artifacts IBM Rational Objective Self-Check Process Enactment / Governance Enforcement / Process Awareness 0% 100% 29 29 © 2012 IBM Corporation
- 30. www.ibm.com/software/rational © Copyright IBM Corporation 2012. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. 30 © 2012 IBM Corporation
Editor's Notes
- Author Notes: This is the PowerPoint template for the Innovate 2012 Track Sessions IBMers can find additional information on presentation resources on Rational’s Managing the Brand W3 Intranet site: https://w3-03.ibm.com/software/marketing/marksite.nsf/AllMarketingPages/Brand-Rational-rt_rtb?opendocument?opendocument Imagery Avoid using cartoon like clip-art, use photo-art instead. Third party material cannot be used in a presentation without written permission (this includes product and Web page screen shots). Images must be acquired from a ‘royalty-free to use’ source such as: Microsoft or Lotus Symphony Clip Art library http://www.freebyte.com/clipart_images_photos_icons/#freevectorgraphics http://www.freedigitalphotos.net/ IBMers can use images from IBM approved image libraries: https://w3-03.ibm.com/software/marketing/marksite.nsf/AllMarketingPages/Brand-Rational-rt_rtb?OpenDocument&ExpandSection=4#_Section2 DAY_01_SYSTEMS_KEYNOTE__v02
- Today, we’re only limited by imagination and what we think we see (see final closing with the additive primary colors). The crowd here in this room are the ones building the future – feel good! Customer Examples… (JPL going to the moon, medical devices, smart card…) YOU take us forward… If we’re already seeing what we thought was next, what is REALLY NEXT? Raytheon Exoskeleton Robotic Suit Image Source: http:// “XOS 2 test engineer Rex Jameson plays soccer during a demo at the Raytheon Sarcos research lab in Salt Lake City, Utah. Photo courtesy of Raytheon Company.” multivu.prnewswire.com/mnr/raytheon/46273/ Sensory Substitution Device Image Source: http://inhabitat.com/israeli-scientists-develop-star-trek-visor-that-enables-the-blind-to-see / © All rights reserved to The Hebrew University of Jerusalem “Dr. Amedi wearing one of the SSD devices developed as the result of research in his lab” DAY_01_SYSTEMS_KEYNOTE__v02
- The people in this room have the power to shape our tomorrow… because let’s face it - our world is changing, and at a pace few of us can comprehend. This unprecedented change is being driven by: Global integration Increasingly complex supply chains and empowered consumers Changing the corporate model and the nature of work itself Movement of information, work and capital across the globe Brought about by increasingly smart networked technologies that talk to each other 24x7 An explosion of bandwidth Where software is catalyst DAY_01_SYSTEMS_KEYNOTE__v02
- <mouse click> <plus signs appear between the boxes and the globe> This is enabling new levels of collaboration. …. connecting the workplace and the marketplace in ways never imagined before <mouse click> <the pluses disappear> <mouse click> <the boxes slide into each other> <mouse click> <they form a small circle> At the same time, our planet is getting smaller. Globally distributed workforce Integrated value chains composed of suppliers, business partners and customers The new flexibility that Kristof spoke of when you think of delivering technology and services via the cloud Our developing embedded software for mobile devices. These are real trends affecting companies like you today. DAY_01_SYSTEMS_KEYNOTE__v02
- Yet at the same time, something else is also going on – something that is affecting our society, businesses and our individual lives…the planet is also becoming smarter. … in that the systems and processes that enable physical goods to be designed, developed and managed are becoming: Intelligent — updating and evolving to meet unique customer needs. Instrumented and infused with software to increase functionality and deliver new kinds of services And Interconnected , creating systems that deliver enhanced quality and value. And as a result, we are all having to think of how things get done and how to do them better. DAY_01_SYSTEMS_KEYNOTE__v02
- Nowhere may this transformation be more evident than in the creation of what all of us to in this room - smarter products From automobiles to the onstar to the satellite to the service center From the artificial hearts to the monitors From aircraft that communicate with each other and the ground crew From wind turbines that adjust to the weather conditions and connect to our power plants… to the electronic devices that connect people and enable the luxuries that we have become accustom Today’s smarter products no longer deliver a single functionality; or operate in a vacuum. They are increasing providing multidimensional and personalized functions in a systems of systems environment They are essential to making our lives more efficient, reliable, healthy and delightful. Nowhere may this transformation be more evident than in the creation of what all of us to in this room - smarter products From automobiles to the onstar to the satellite to the service center From the artificial hearts to the monitors From aircraft that communicate with each other and the ground crew From wind turbines that adjust to the weather conditions and connect to our power plants… to the electronic devices that connect people and enable the luxuries that we have become accustom Today’s smarter products no longer deliver a single functionality; or operate in a vacuum. They are increasing providing multidimensional and personalized functions in a systems of systems environment They are essential to making our lives more efficient, reliable, healthy and delightful. And are the building blocks for our future…and smarter planet Which is exciting – if we can pull it off. But is also a little scary for those of us in the room who have to make this vision a reality…. For the SE… For the SW…. DAY_01_SYSTEMS_KEYNOTE__v02
- Optimize systems behavior Maximize product quality Converge engineering disciplines [Main point of the slide: For companies developing smart products to remain competitive, they must acknowledge at least three imperatives, all of which are focused on taking a systems engineering approach to product development that raises the traditional focus on physical design to a higher level multi-disciplinary approach that better fosters innovation.] The main message of this slide is to emphasize the imperatives for companies that want to improve their competitiveness in developing smart products. These companies have been told for years by PLM vendors that using their PLM products for detailed design will give them everything they need to maximize innovation and reduce costs. However, this advice misses some key points that have become much more relevant in recent years as software content within smart products has dramatically escalated, changing the way product development must be approached. [Main point behind “Optimize systems behavior”: Detailed design, a strength of traditional PLM vendors, locks in design decisions, discouraging design iteration and experimentation, which are key to innovation. The behavior of the smart product as a system, however, can and should be optimized early in the design process, where cost of change is low, and where design decisions have maximum impact on product performance, cost and quality.] Today’s smart products can no longer be designed simply as physical devices with some electronics and software thrown in. In fact, these products are complex systems, comprised of a hierarchy of sub-systems, all of which must operate in harmony to ensure proper function of the product. Much of the innovation in today’s products comes well before the detailed design phase; in fact, it comes as systems are being defined and various aspects of behavior and function are being assigned to specific sub-systems. This is called functional and logical design and can be quite complicated—enough so that specialized modeling techniques are required to manage the overall complexity. However, it is during functional and logical design that the overall behavior of a smart product can be defined at the highest level, and it is here that systems behavior should be optimized. After detailed design begins, design decisions become documented and locked in, and further iteration and change is naturally discouraged. Leading companies optimize product behavior as defined within the systems that comprise the product. [Main point behind “Converge engineering disciplines”: Traditional approaches to product development (such as PLM) are discipline-centric, and are not designed to view design decisions outside of their own domain. Successful product development organizations must view the design and the impact of design decisions across all engineering disciplines—to understand the impact of one discipline on another.] Similarly, a systems engineering approach looks at product behavior and functionality across multiple engineering disciplines, meaning that it helps understanding of how the disciplines interact together. Traditional approaches focus on the mechanical engineering aspects as documented in detailed design, and then look at the effects of electronics and software. Without the rigor of systems engineering, it’s difficult to understand how all the disciplines truly interact, for instance, how to propagate the effect of a change in one discipline to another. Innovative product design calls for organizations to converge engineering disciplines using the guidance obtained from systems engineering principles. [Main point behind “Maximize product quality”: It’s easy to talk about the importance of product quality, but balancing quality and cost are difficult, as any level of quality can be achieved with enough cost. The key is to ensure that product requirements are tested—no more, no less. This is achieved by linking requirements and tests (traceability), at all levels of design—functional, logical, and physical (not just physical as is the case with PLM).] It goes without saying that product quality should be maximized—but at what cost? There’s always a tradeoff, as enough time and money thrown at quality is sure to increase it. There are smarter ways to build in quality, principally by ensuring that the product requirements that define the product are mapped directly to tests that verify those requirements. Though it sounds simple, traditional product development environments don’t maintain this simple relationship between requirements and tests. This level of traceability is mandatory in an efficient development environment. In fact, this traceability needs to exist not only in the physical product definition, but in the functional and logical designs as well. In summary, all three of these imperative reinforce each other in support of systems engineering principles. Adhering to one of the principles is good, but adhering to all three will generate a huge boost to competitiveness in developing smart products. DAY_01_SYSTEMS_KEYNOTE__v02
- Improve agility Responding to changing market and customer demands is a key concern for software developers - 49% of embedded SW development organizations cite scope creep and changing requirements as their top challenge. This is driving a move to more agile processes, replacing big design up front with focused iterations and prioritizing what really matters to ensure that the right product is developed. Best in Class companies are more likely to use agile practices: For example they are: 39% more likely to keep code as simple as possible 40% more likely to conduct peer reviews of code 27% more likely to write software in small verifiable steps 66% more likely to colocate developers during development 147% more likely to pair developers (peer to peer collaboration) (From Aberdeen Group: The Future of Innovation in Tomorrow’s Products, September 2011) Compliance Complex software-based systems have increasingly significant safety, financial and even societal consequences of failure which must be managed through increased standards of dependability. This is driving the development and adoption of industry standards and the need to incorporate standards support into development processes and tooling. Aberdeen Group found in 2011 that 22% of companies cited the need for regulatory and standards compliance as a top business pressure driving improvement in embedded software development compared to 10% in 2009. From the market perspective compliance is a hygiene factor – it must be provided without adversely affecting costs or delivery timing. Automation is key factors in streamlining compliance—by building support for standards into processes and the tools that enact them, teams can automate otherwise productivity-sapping activities such as data gathering and the generation of required documents. And compliance and agility don't have to be in contention – by building compliance into agile processes companies can achieve their compliance objectives whilst delivering the responsiveness required by today’s markets. (From Aberdeen Group: The Future of Innovation in Tomorrow’s Products, September 2011) Integrate HW/SW development What matters in the marketplace is working products and systems. Whilst much of a product’s capability stems from software it can’t be developed independently. As software functionality and complexity increases, so does its dependency on hardware. Changes and defect fixes must be synchronized across hardware and software development teams to avoid costly, schedule-busting integration issues. This means fostering a development environment where HW and SW teams can collaborate and share timely, accurate information as the design evolves. To achieve this companies must pay close attention to both processes and tooling. In their Future of Innovation in Tomorrow’s Products report Aberdeen Group found that 48% of best in class companies were using some form of HW/SW dependency management compared to an industry average of 33%. (From Aberdeen Group: The Future of Innovation in Tomorrow’s Products, September 2011) DAY_01_SYSTEMS_KEYNOTE__v02
- Product manufacturers must manage increased complexity when developing smarter products. IBM announces solutions that enable product manufacturers to: Accelerate development by integrating across the complex software and systems supply chain Access a growing and extensive business partner ecosystem Reduce risk in high-growth industries through targeted accelerators DAY_01_SYSTEMS_KEYNOTE__v02
- It is pretty obvious which approach most designers take in creating everyday products. When we consider the real usage of such systems, we discover new features and combinations of features necessary to meet those needs. Otherwise we risk building feature-rich products that are both overly complex and which don’t meet real user’s needs. They don’t support how the users will actually want to use them. All GPS Navigation Systems have the features listed here, but few if any will perform all of the example usages listed here, yet these seem like perfectly reasonable things to do, and they are not harder to implement than the other features included but perhaps not as useful. What’s needed is study and modeling of how the system will actually be used in practice.
- The long-term goals of this solution approach include the capability to: - Manage cross-domain changes through a centralized requirements change management process - Reduce the time to propagate changes throughout the entire design team Reduce discovering ‘missed’ changes late in the project - Improve management of multiple engineering disciplines Increase visibility and communication Obtain a more complete impact analysis of changes – with cross-domain visibility Better manage schedules, time to market, costs and ROI - Leverage existing investments in Software and Systems development platforms
- Web view of a Rhapsody model in Rhapsody Design Manager Browser showing design information is on left can be used to navigate the design in a very similar fashion to the Rhapsody client browser Comments are added on the right which can be supplemented with diagram mark ups
- But first let’s talk a little bit about the documentation challenges organizations face today. To create internal documentations for various purposes, organizations can run into several issues which could come from various factors including scaling or globalization, regulatory requirements, or simply trying to inform their staff. They can run into missing information in their documentation or format inconsistencies they have to deal with because the documents just simply don’t look good and they are inconsistent. Add to that the need to gather information from disparate applications or teams and place them in a single document and the whole process becomes extremely complex. Now you have to open each application and cut and paste into a single document. In many companies engineers seem to be overwhelmed with both content and formatting of documents. They end up not only having to worry about making sure that the information is accurate but also ensuring that it’s formatted correctly. And a lot of times what we see is that the documentation isn’t always up to date properly so the team and management is misinformed. Reviews are wasted on misinformed decisions, while engineer work off of old specs. The problems could be endless and the end it could indirectly affect the quality of your product. So documentation internal or external is very important. So how could you deal with some of these challenges? Internal Note : Some of the issues customers could be facing are: We don’t get paid if up-to-date documentation is not delivered. How can we make sure that everything is up to date? Not everyone uses DOORS How do I show information to management and …? Engineers should not be responsible for content AND format How do I off load and automate some of their work? Repetitive periodic reviews are part of our process How can we streamline document preparation for meetings? We need to report on the same data from many different perspectives We need to ensure consistency of format across the organization
- The key to success is separation of the content issues from your formatting issues . Normally what happens is that project engineers manipulate their requirements and models in some quirky fashion just so it will be useable in a document later on. It’s an improper use of engineering time to worry about keeping their data in a useable format for documentation purposes. For that what you will most likely get, is data compromised for the sake of formatting. That’s another reason they can’t worry about formatting. That needs to be done for them. But then you run into another problem. If you need a way to merge the format and content, efficiently and on demand. That’s where automation of the product documentation lifecycle with Telelogic Publishing Engine comes handy. TPE is a template based tool that automatically produces documents directly from information contained in data sources it supports. TPE uses a knowledge base of development methods, capture notations, data sources and document standards to find extract, format and place project engineering information into appropriate sections. Included predefined and user-definable templates ensure compliance with both formal and company-specific publication standards. TPE allows very diverse content types to be combined, and structured so that the result is a great looking, functional set of documents. It can do this fast enough so that the resulting document stays in synch with the true state of the project while relieving tool users of formatting details and headaches of getting diverse tools to format the same way. In more detail, you can see that TPE can extract information from a wide range of content sources; Our own products such as DOORS, Tau and also any 3 rd party content sources capable of exporting their data as XML. Once TPE has extracted data, it can organise it using industry standard or company defined templates, and then publish to a variety of popular formats, so TPE can be your single document generation environment.
- Author Note: Mandatory Rational closing slide (includes appropriate legal disclaimer). Graphic is available in English only.