Is model based engineering suitable for the ‘Internet of Things’?

Ever since I heard of ‘Internet of Things (IoT)’ and how it is going to revolutionize everything in the world by connecting human and non-human ‘things’ to enhance efficiency, ease and consumer experience; I was beginning to doubt if current technologies and tools to develop products could cope up with it. I began to investigate more to find out how IoT will transform not just engineering businesses, but how in turn it will affect companies that develop ‘things’.

New challenges for product engineering companies

Before that, I found out that the McKinsey values the market potential from IoT as $2.7-6.2 trillion in 2025 and Gartner that “By 2020, Internet of Things Will Create $1.9 Trillion of Economic Value Add”. Clearly there is significant opportunity for the Internet of Things.

As I went deeper, I figured out that in order to connect humans to ‘things’, companies developing them need to first go through a transformation of how they build products and most importantly, realize how they are interlinked with other products, and in turn, linked to services of all kinds e.g. operations, maintenance, transport, etc.

There are enormous and new challenges that product development companies have to think about and come up with solutions. Challenges that they never cared about when they operated stand-alone, mostly up till now.  To summarize, to research the effect of IoT I narrowed down on the following challenges that any product development company developing connected products, has to keep in mind:

• Delivering the required functionality (where the requirements might be continuously changing)
• Delivering appropriate dependability in the form of safety (freedom from harm), reliability (availability of services) and security (freedom from intrusion, interference or theft)
• Delivering the solution in an ‘open’ context—where some of the technologies and components that contribute to the solution are not under direct commercial or engineering control
• Delivering the solution with appropriate speed and at appropriate cost to meet the commercial objectives of the solution

The list may grow depending on the unique needs of a particular industry such as Consumer Durables, Medical Devices, Automotive, Aerospace, but I guess the above four are fundamental challenges for a product developer whose products will be part of an IoT system.

A new development process is needed

In light of these challenges, there is a significant need for a development process that includes a whole new way to look at how we build products and their relationships to the larger connected eco-system. A colleague of mine recently published an article on the engineering approach that a product development company should take when their product/system becomes part of another system. In other words, engineering for ‘system-of-systems’. You can read more in Dr. Barclay Brown’s ‘Systems Engineering and IoT‘. What Dr. Brown illustrated in his article was the approach of Systems Engineering to bring in the view of looking at systems holistically.

I would like to go a little deeper and emphasize on particular area of this approach, which was briefly touched upon in his article – system Validation and Verification (popularly known as V&V). I believe that this is one of the most critical aspects of the entire development process for connected products. It is through this step that we make sure:

• What we are developing is correct
• It performs the way it should be
• It connects to the eco-system the way it is meant to be
• It complies with safety standards
• Most importantly, it is commercially viable

Imagine if your connected product has missed out one of the above conditions. Delay in time to market of your product; increased production costs and losing market share to your completion are some of the possible outcomes.  Now, imagine you have already satisfied all the above conditions even before your first physical test product is built. Wouldn’t that be great?  With advancements in tools and solutions available to help you accomplish that, this is now a reality. This possibility in technological terms is ‘Continuous Validation and Verification’.

Continuous Validation and Verification

Let me explain these concepts in a little more details – ‘Validation’ is the process through which engineers continuously check if a product meets the requirements of customers and they are building the right product. Whereas through ‘Verification’ one can compare the designs and implementations against those requirements and ensure that the product is being built correctly. Key questions engineering teams struggle with are:

• How can I explore my requirements and designs with my customers better?
• My hardware won’t be ready for months how can I verify the behavior of the software and hardware together and reduce my technical risk earlier?
• How can I optimize my design choices before we sign the contract and start production?
• How do I build a physical prototype to run all of my tests when I have to go through iterations with changing requirements?

Continuous Validation & Verification helps to address these issues. By creating virtual prototypes using computers, models and abstraction to analyze the product, it is possible to share design ideas with customers and other stakeholders early and secure their feedback on requirements – in other words we validate designs.

To ensure that the right product is built, verification is done throughout the development stages by early definition of test cases which can be traced to customers’ requirements and ensures all the requirements have a test case associated with them. These test cases can then be continuously run in an iterative fashion as the design evolves to ensure it does not deviate from the customer’s initial intent and engineers can be automatically notified of such a failure. Additionally, when a requirement is changed it is easier to understand its impact on the rest of the system. You can even ensure that the product you are building complies with various industry and critical safety requirements during this stage and throughout.

Is ‘model based engineering’ suitable for IoT development?

Now, going back to the ‘doubt’ that triggered me to pen down my thoughts – whether Model Based Engineering is suitable for IoT development although perceived to be slow and too process driven? The answer to that is a question that we should ask – does speed of delivery determine the success of your product or the quality of the product itself? Speed may help you get your product out there first in the market, but majority of those could be defective and that will eventually be pushed out of the market or will require recall at huge expenses.

There are many such recalls in Aerospace & Defense, Medical Devices and Electronics industries. The nuance here is that quality issues leading to in-service rectification actions affect different industries in different ways.

High volume industries such as Automotive can incur high costs from seemingly minor, cheap-to-fix issues, whereas low volume, highly critical industries (Aerospace and Defense, some medical equipment manufacturing) can have very high cost of failure challenges. If faulty products operate as part of the IoT ecosystem the risk and cost of failure may multiply and spread across other related products and services. There is too much at stake to building something where the quality is not right.

Source: Wikipedia

For example, consider an anti-lock brake software recall

In total, Toyota recalled three hybrid vehicles to reprogram the anti-lock braking (ABS) software. A total of 133,000 Prius vehicles in the U.S. and 52,000 in Europe received the same software update. Affected vehicles for anti-lock brake software recall included the Toyota Sai, Toyota Prius (2010 model year) and the Lexus HS 250h (2010 model year)

Model Based Engineering can help tackle the number of failure modes and unintended consequences and issues, at a stage when correcting errors will cost the least. I think it makes sense to adopt this approach for developing connected products.

The essential capabilities of the development process

I have summarized the benefits of adopting Model Based Engineering below. These benefits are not specific to IoT product and systems development; however the potential increase in complexity, number of failure modes and possibility for unintended consequences means that these capabilities become essential within the development process.

• Demonstrate requirements coverage (Requirements Elicitation, Requirements Coverage and Continuous Customer Validation)
  – Ensure every requirement is supported by a test
  – Be alerted when tests fail or requirements change
  – Automate testing and test management
• Employ an analysis and simulation driven approach for requirements and design
  – Use Model Based Engineering (MBE) for requirements specification
  – Verify architecture and designs using system level analysis
• Utilize multi-domain hybrid simulation
  – Integrate multiple platforms/components supplied by different companies in the supply chain
  – ‘Verify by simulation’ (software, hardware, cyber-physical)

If you are thinking of adopting Model Based Engineering, here are some links to free trials of  products/solutions from IBM IoT Continuous Engineering:

For validation through modeling and simulation – IBM Rhapsody Product family

For verification & testing – IBM Rational Quality Manager

For managing requirement – IBM DOORS Next Generation