President's Message: FDA Applying Systems of Systems Approach to Deal with Cybersecurity for Medical Devices and Healthcare

I recently attended a webcast hosted by the Food and Drug Administration (FDA) to address cybersecurity for medical devices and healthcare.  It was a call to action to engage medical device manufacturers, healthcare organizations, the FDA and other government agencies, such as the Department of Homeland Security (DHS) to address the advanced and persistent cyber threats to systems.  Cybersecurity is fundamentally a people problem which is enabled by technology, people are responsible for initiating attacks and the internet of everything is exploited to facilitate these attacks.

The FDA regulates medical devices but there are over 100,000 medical devices, so there is expectation that manufacturers are assessing risk and taking control measures.  The FDA does not regulate the healthcare providers which represents a vast spectrum from national institutions like the Veteran's Administration Hospital to individual doctors.  This is one of the pain points identified for systems of systems, no central authority.  The FDA strategy is to foster collaboration in order to address the vulnerability posed by cybersecurity. This affects medical devices as well as healthcare providers and any breach to these systems could lead to an attack on other systems which is why DHS is engaged.

The systems of systems’ need for inter-operability drives requirements for inter-connectivity which exposes cybersecurity vulnerabilities.  Inter-operability improves efficiency to provide healthcare which improves patient care but also boils down to economics.  This is a tradeoff between information access and security.

The National Institute of Standards and Technology (NIST) defined a framework for improving cybersecurity.  A core element of the framework is the identification of the risk.  The risk assessment considers the interfaces of the constituent systems in the risk environment.  This is challenging because as previously stated healthcare providers represent a vast spectrum which inter-connect systems in variety of ways.  Also, some medical devices are classified as legacy devices because they have a long service life and may lack security features. When these legacy devices are interfaced with other systems they present a vulnerability to the systems of systems.  Another core element of the framework is detection of an attack.  Detection is always after the fact so focus is on remediation.  The reporting of attack is an interface that needs to develop in order to share the information and reduce the risk to other systems.  A common model to bridge organizational barriers, sectors and address concerns about reputation, liability and intellectual property needs to be defined.

An element of the discussion that I found particularly interesting is the human aspect.  While there is the obvious human aspect of the hackers who initiate the attack, the healthcare providers are hackers in their own right.  The healthcare providers' priority is to patient care and they are resilient at devising workarounds to use the systems at their disposal.  Additionally, availability of systems to provide care trumps security, so even if vulnerability is detected but the system can continue to satisfy its intended use, it will be used.

Throughout the two day webcast attended by a large diverse community the theme of systems of systems was repeated.  Cybersecurity is a multi-faceted wicked problem covering economics, technology, human factors, political, physics and math.  Numerous constituent systems are involved.  It requires systems thinking.  The FDA is facilitating a collaborative environment to provide leadership in solving these issues.  The mission of the FDA is to ensure that medical devices are safe and effective and to ensure security going forward.

By Rollie Olson

INCOSE SFBAC President 

Rollie Olson's Bio

The Internet of Everything: A Stanford Engineering Symposium

Stanford Engineering is holding a symposium on The Internet of Everything. Any member of the community can view the live event free by registering and signing up through Stanford Center for Professional Development (SCPD) by 4pm on December 4, 2014 here: http://scpd.stanford.edu/search/publicCourseSearchDetails.do?method=load&courseId=27224811. The symposium will take place Thursday, December 4, 2014 from 7:00 - 8:15 pm.

About the symposium:

A quiet technology revolution has made it possible for many objects to communicate electronically. Already more objects than humans are connected to the Internet, a trend that will only increase as more TVs, eyeglasses, watches, thermostats, cars and sensors link to the Internet and each other. Stanford Engineers and others are creating something new, a network of humans and things. It is the Internet of Everything.

Attend our next EngX symposium to hear from three Stanford Engineering faculty members working to create the Internet of Everything and learn more about the engineering challenges that surround it. EngX is a fast-paced event with three 20-minute talks and questions afterward.
 
Speakers

• Thomas Lee, a professor of Electrical Engineering, will provide an overview of the Internet of Everything and what it could enable. He has been researching wireless technology at Stanford University since 1994 and is a past Director of DARPA's Microsystems Technology Office. 
• Mark Horowitz is the Yahoo! Founders Professor at Stanford University and was chair of the Electrical Engineering Department from 2008 to 2012. He will talk about how Stanford engineers are investigating ways to build a secure Internet of Everything. Horowitz is a member of the National Academy of Engineering and the American Academy of Arts and Sciences.

• Armin Arbabian, an assistant professor of Electrical Engineering, will discuss the ant-sized radio he created, an inexpensive, self-powered radio controller that provides the web of connectivity and control between the global Internet and smart household devices - an essential requirement for the Internet of Everything.

Please note this event is not hosted or connected to the INCOSE SFBAC Chapter.

INCOSE SFBAC Election & Survey

The SFBAC is accepting votes in the election of our 2015 chapter officers and feedback for the end of the year poll until Friday, December 19, 2014. 

Voting members, we have one update for this year's election. Members are limited to 6 votes in the BallotBin field that allows votes for candidates (this should have been 7). We apologize for any inconvenience or confusion this has caused. 

If you believe you have paid your member dues for 2014 but have not received a ballot, contact Dorothy McKinney at dorothy.mckinney at INCOSE.org.

Systems Engineering in Transformation

The Systems Engineering Transformation Caucus is working toward the development of a systems engineering practice that:

• Brings in new practices and new methodologies dynamically,
• Adapts and responds to circumstances, and
• Constantly evolves as new insights and practices emerge. 

 This year the caucus established a public website at:

http://transformationcaucus.wikispaces.com/Shared+Transformational+Systems+Engineering+Resources

The resources at the public website include a review of presentations at this year's INCOSE International Symposium.  (See URL, above, for a summary of the presentations.)

The caucus is currently working on a variety of fundamental issues in TSE practice.  We are committed to presenting a snapshot of this work in papers published in the Autumn 2015 issue of INCOSE INSIGHT.  We are also planning to meet at the INCOSE International Workshop in January of 2015 to review drafts of these papers.

Issues addressed in the INSIGHT papers will include:

• TSE Vision - What is our vision of Transformational SE and what are the integrating concepts for TSE?  Lead:  Scott Workinger
• Situation Awareness - What are the relevant factors to consider when choosing TSE practices and what factors should be monitored to keep a TSE project on track?  Leads:  Dean White, Dorothy McKinney
•  TSE Integration Framework - When establishing a TSE framework of practice, what is needed to establish plug and play interfaces for individual TSE Practice Components?  Lead:  George Sawyer
•  Business Models and Organizational Factors - How does an organization's business model influence the choice of TSE practices?  What are the organizational factors needed to support various TSE practices?  Lead:  Lee Amon
•  Group Flow - Both Design Thinking and Agile Development harness the creative power and productivity of group flow.  How can TSE practices initiate and sustain group flow?  Lead:  Laurie Buss
•  Agile Development - What are the available ways to bring Agility into a Project?  How do we measure Agility?  Lead:  Clark Ince
• Agile Development - How do we scale up agile methods to large projects?  Lead:  Phyllis Marbach
• Design Thinking - What is Design Thinking and how does it differ from Classical Systems Engineering?  Lead:  Jean Souza
• Design Thinking - How does design practice differ in successful design organizations?  (Three major Silicon Valley companies will be studied including some that employ very large development projects.)  Leads:  Uli Barnhoefer, Scott Workinger
•  System of Systems Engineering - What are some key examples of successful architectural patterns in System of Systems Engineering practice?  Lead:  Ray Deiotte 
• Validation in Transformational Test Engineering - In an environment where many systems cannot be tested using classical techniques, how can complex systems be tested and evaluated effectively?  Leads:  Andy Anderson, Scott Workinger

Jean Souza has graciously accepted the role of TSE Co-Leader.  Since stepping up to the Co-Lead position, she has played a key role in moving the publishing effort forward.

The caucus has been making regular presentations at chapter meetings for INCOSE SFBAC (serving Silicon Valley).  For instance:

• The October Meeting featured Lee Amon discussing how Silicon Valley Business Models will, in many situations, lead to the application of differing systems engineering practices.
• The November Meeting featured Dean White and Dorothy McKinney discussing the relevant factors in establishing Situation Awareness for applying practices and monitoring the evolution of TSE projects.

The caucus welcomes the participation of interested individuals.  For further information, please contact:

• Jean Souza:  jmsouza at fastmail.fm
• Scott Workinger:  scottworkinger at gmail.com

 

By Scott Workinger, Ph.D.

INCOSE SFBAC Past-President

Scott Workinger’s Bio

December Membership Meeting Cancelled

The INCOSE SFBAC will not be holding a meeting December 2014. Information on future meetings will be posted on our chapter's Schedule of Events page: http://www.incose.org/sfbac/schedule.html

President's Message

As the year draws down, I thought I would reflect on what being a Systems Engineer means to me.  You may have heard the CNN story about Systems Engineering being America's best job.  Despite having gone through two downturns as a Systems Engineer, transitioning between defense reconnaissance to offensive weapons systems and recently to medical devices, I still believe this to be true.  The practice of systems engineering involves a multidisciplinary view to solve problems which continues to expand my knowledge and appreciation for all of these individual practices and it sure is not boring!

 

  Individual Practices Contributing to Systems Engineering

Source: http://seor.gmu.edu/insert/intro/SE/introrol.html

My personality type is introvert; but I find the opportunity to work closely with a team to understand the user’s need, synthesize a design to address it and present it to them to validate that we correctly identified a solution to be extremely rewarding.  There are ample examples where systems engineering was not applied and the resulting solution fell short as seen below.

Solutions Lacking Systems Engineering

Source: http://www.projectcartoon.com/

While degrees in Systems Engineering are being offered, I became a Systems Engineer through career development.  I do not recall when I was given the job title of Systems Engineer because I believe that I have always looked under the covers of every job I have worked on to understand how my contribution benefits the whole system.  I am disappointed to say that I have not progressed on my intention stated in June newsletter to pursue my SEP certification.  Between work, family and my duties as president, I have not found the time nor energy necessary to complete the application, contact references and study the INCOSE Handbook.  However, I want to acknowledge Clark Ince, Chapter Treasurer, who did earn his CSEP.

I am interested in hearing from you and welcome feedback on what the chapter can do to meet your interests and needs.  Also, as the end of the year is near, if you are interested in volunteering to be an officer or director for the chapter, please contact myself or any of the current officers. The current list of officers can be found here: http://www.incose.org/sfbac/officers.html

By Rollie Olson

INCOSE SFBAC President

Rollie Olson's Bio

 Source: http://www.cafepress.com/

Upcoming Membership Meetings: October & November

The INCOSE SFBAC will be holding meeting on October 13 and November 10, 2014. Information on speakers, topics, and location will be posted on our chapter's Schedule of Events page: http://www.incose.org/sfbac/schedule.html

Improved Traceability of Mission Concept to Requirements Using Model Based Systems Engineering (MBSE) a Thesis Summary

Model Based Systems Engineering has recently been gaining significant support as a means to improve the “traditional” document-based systems engineering (DBSE) approach to engineering complex systems.  There are many perceived and proposed benefits of an MBSE approach, including enhanced communications, reduced development risks, improved quality, and increased productivity (A Practical Guide to SysML, 2nd Ed.).  However, while many groups have published descriptions of their early modeling efforts or potential benefits from those efforts, little analysis has been presented to determine the experienced benefits of such an approach.  The goal of this thesis summary is to present direct examples of how developing a small satellite system model can improve traceability of the mission concept to its requirements.

A comparison of the processes and approaches for MBSE and DBSE was made using the NASA Ames Research Center SporeSat mission as a case study.  SporeSat, a 3U CubeSat launched in April 2014, performed a 3-day experiment in low-Earth orbit to study fern spore growth in varying gravity environments.  Mission concept and requirements documentation from the early mission development phases, in the form of Microsoft Word and PowerPoint documents, were used to create a model of the mission using the Systems Modeling Language (SysML) standard and No Magic’s MagicDraw modeling tool.  SysML’s “dependencies” depict the various relationships between model elements.  Dependency Matrices help to analyze the completeness and consistency of the requirements to the mission concept.  These matrices made it possible to quickly check for holes or extra information in the mission concept and requirements.

The model consisted of different types of diagrams to depict the structure and behavior of the SporeSat mission.  The main dependencies used to relate the mission elements include the Satisfy, Trace, and Allocate relationships.  A process for tracking potential issues with the model’s completeness and consistency was implemented using the Problem and Comment stereotypes of SysML.  In the following figure, the Satisfy and Trace relationships are used to relate Activity and Constraint model elements to Requirements, and a Problem is linked between a Requirement and the Activity that traces to it.  The Satisfy dependency was used to indicate that a Requirement was properly satisfied by some structural or behavioral element of the mission concept model.  The Trace dependency worked similarly, except it indicated some sort of problem with the relationship between the related elements.  The Problem contained an explanation of the issue suggested by the Trace dependency.

Problems could also be tracked in a Dependency Matrix, allowing for the modeler to quickly determine how many problems existed in the model.  Interviews were conducted with the SporeSat Lead Systems Engineer (SE) to analyze the nature of each problem and ultimately assign each Problem a specific designation, described below.  Once a problem had been fully understood and categorized via this designation, its stereotype would be changed from Problem to Comment.  The Dependency Matrix could be monitored throughout this process to determine which, and how many, Problems had yet to be analyzed.   For instance, at the time of capture, the example Dependency Matrix below still contained two unaddressed Problems (circled in red). 

A Satisfy/Trace dependency matrix was created to track the status of all mission requirements; each Satisfy and Trace relationship would appear on the matrix as an arrow pointing from the mission element to the requirement it satisfied or traced to.  Any requirement without at least one Satisfy or Trace relationship tied to it would lack an arrow pointing to it, as well as have a blank in the package summary column below it (see requirements circled in red below).

In the span of the two-month long modeling process, a total of 41 problems were created and addressed concerning the completeness and/or consistency of the mission concept.  Fourteen of these were resolved, having been caused by a simple lack of understanding of the mission or a lack of accessible information.  The other twenty-seven issues were considered “unresolved,” meaning they were real problems with the mission concept as provided in the original documentation.  These problems were categorized as shown:

Unresolved Problems
Vague Implication	Missing, implied information	2
Not Verifiable as Written	Requirement that, as written, cannot be verified	3
Redundancy	Model elements that repeat each other (usually requirements)	4
Nomenclature Inconsistency	Different terms used for the same thing, or the same term used for different things	5
Outdated Documentation	Inconsistency due to documentation not being updated together	13

The SporeSat Lead SE already knew about the problems prior to the modeling process.  While the model did not present any unknown problems, it did prove its usefulness for identifying and highlighting potential issues with a mission concept.  The dependency relationships and associated matrices emphasized holes and extra information in the mission concept, as well as helped to identify and track unsatisfied requirements.  Though all the problems in the model were previously identified by the team, the model highlighted the potential for issues to exist that they were not aware of and its ability to assist the modeler in finding those issues.

By Robin Reil

SFBAC INCOSE Secretary

Robin Reil's Bio