Will PLM and ALM prevent a car from being hacked?

July 23, 2015

wired-jeep-hack-plm-alm-integration

Integration of hardware and software is a topic in mind of many manufacturing companies these days. PLM was traditionally focused on mechanical and lately on electronic topics cannot ignore more software. Software developers are using a different set of tools for configuration management. For long time ALM (Application Lifecycle Management) tools took a separate stand from PLM tools. All these things in the past. Software vendors and manufacturing companies cannot ignore complexity of modern product literally powered by software in every part. I’ve been blogging about it long time ago – PLM and ALM: How to blend disparate systems and lately – How to combine engineering and software BOMs.

In one of my last posts – The importance of software BOM for hardware security, I pointed out how important to get an access to right information about software and electronic running in your products. For many manufacturing companies the information about mechanical, electronic and software components is siloed in different data management systems.The importance of new tools capable to manage multidisciplinary product information is raising. Software BOM security is just one example of the trend. The demand to provide systems able to handle all aspect of product BOM is increasing.

The article in WIRED magazine few days ago brings an interesting perspective on the importance of software security in automotive products. Navigate to the following article – Hackers remotely killed a Jeep on the highway – with me in it. The story is fascinating and gives a lot of "food to think about". Here is my favorite passage:

All of this is possible only because Chrysler, like practically all carmakers, is doing its best to turn the modern automobile into a smartphone. Uconnect, an Internet-connected computer feature in hundreds of thousands of Fiat Chrysler cars, SUVs, and trucks, controls the vehicle’s entertainment and navigation, enables phone calls, and even offers a Wi-Fi hot spot. And thanks to one vulnerable element, which Miller and Valasek won’t identify until their Black Hat talk, Uconnect’s cellular connection also lets anyone who knows the car’s IP address gain access from anywhere in the country. “From an attacker’s perspective, it’s a super nice vulnerability,” Miller says.

From that entry point, Miller and Valasek’s attack pivots to an adjacent chip in the car’s head unit—the hardware for its entertainment system—silently rewriting the chip’s firmware to plant their code. That rewritten firmware is capable of sending commands through the car’s internal computer network, known as a CAN bus, to its physical components like the engine and wheels. Miller and Valasek say the attack on the entertainment system seems to work on any Chrysler vehicle with Uconnect from late 2013, all of 2014, and early 2015. They’ve only tested their full set of physical hacks, including ones targeting transmission and braking systems, on a Jeep Cherokee, though they believe that most of their attacks could be tweaked to work on any Chrysler vehicle with the vulnerable Uconnect head unit.

While story is still under development, it is already raised many questions. Some of them led to discussion about standards for cars’ defense against hackers. I’m expecting an increased demand for software capable to manage traceability and tests of mechanical, electronic and software systems together to insure car is not vulnerable to potential hacks.

Manufacturing business technology article echoed the same topic –Software Integration With Hardware Crucial For Manufacturing. It confirms that hardware – software integration is complex and very few companies are doing it in a right way. It gives interesting recommendations how to improve that – common data model, integrated requirement and change management tools and a framework independent from software tools. A common data model is my favorite. Here is a quote:

A common data model. Unified ALM-PLM defines a common data model and change management processes for managing an entire system, both hardware and software data, without duplicating data management or business processes across those systems. The two primary integration points are, first, tying back the requirements to the software and hardware bill of materials and, second, linking defects back to change requests and change orders so PLM can reflect them.

While all recommendations make sense to me, I have a concern about their implementations in real life. How feasible to create a common data model using existing PLM and ALM software tools? A dream data and lifecycle management system should be flexible enough to handle all system definitions from mechanical, electronic and software as well as system behavior related to that.

What is my conclusion? The complexity of modern products is creating demand for new capabilities to support by PLM and ALM software. While integration is usually hardest part of PLM implementation, not all PLM system are flexible enough to maintain demanded "common data model" to handle all bill of materials and related information. Just my thoughts…

Best, Oleg

picture credit WIRED article


How to Combine Engineering and Software BOMs?

January 24, 2014

PLM-ALM-software-BOM

I remember a conversation that happened to me a decade ago with fellow engineer from one of leading telecom companies. The question I asked him was – how do you know what version of software to load into device? The answer was- "Hm… actually we don’t know much about it. It happens magically". I have to say this company is not doing very well these days. No surprise.

The importance of software lifecycle management is growing enormously. Modern manufacturing products contain mechanical, electronic and software components. To manage data lifecycle for all types of components is getting more and more important.

There are quite many software packages these days to manage software lifecycle. Some of them belongs to respectful software companies and some of them are open source packages. The software category called ALM (Application Lifecycle Management). Navigate to the following wikipedia link if you want to learn more. Here is the definition I captured there:

Application lifecycle management (ALM) is the product lifecycle management (governance, development, and maintenance) of application software. It encompasses requirements management, software architecture, computer programming, software testing, software maintenance, change management, project management, and release management.[1][2]

Recently PLM companies started to be more interested in how to manage software lifecycle too. I can track back PTC MKS acquisition. Also, I was able to Google multiple links about TeamCenter and ALM tools integration. I don’t want to endorse any specific package, so I won’t provide links here. However, you can easy Google them too. I didn’t find any that officially supported by Siemens PLM.

I want to go down from formal ALM marketing buzzwords and speak about Bill of Materials. How software BOM is different from Engineering BOM? Can we use similar tools? Can we share the same set of BOM management practices when it comes to software compared to components? How we can present overall product lifecycle? Browsing various forums, I found an interesting passage on Jboss forum about how to use bom with Maven:

A bom is a so called bill of materials – it bundles several dependencies to assure that the versions will work together. JBoss has boms for many of it’s projects, including Arquillian and the JBoss AS itself.

The statement made me think how actually engineering BOM can be different from software BOM in terms of product lifecycle management as well as how both software components can (or should) appear in unified bill of materials and, even broadly, should we have unified BOM containing mechanical and software components?

My attention caught The Manufacturer article Silos changing: PLM and ALM for Smart Products. Article speaks about how to merge together both application lifecycle and "traditional product lifecyce". The following passage seems to be interesting:

Until now, software engineers have tended to use their own design management tools such as Rational DOORS for requirements management; Rational ClearCase for Software Configuration Management and HP Quality Center for Testing. These tools are often bundled together as the Application Lifecycle Management (ALM) category. Physical product design teams for the other disciplines have used Product Lifecycle Management (PLM) tools for design management.

We can confidently say that no single vendor provides every design management and design development tool needed in a single suite. That means there will have to be a best of breed approach. There are several issues to consider. Where is the master of the product requirements maintained? Should the change management of software and physical artefacts be combined in a single system? How will derived requirements such as signals and dependencies between software and hardware components be managed? How will product variants be handled?

PTC’s purchase of MKS and its Integrity product line provides, for the first time, a single vendor PLM and ALM solution.

The following link leads to PTC Integrity software white paper (formerly acquired MKS). I downloaded ebook for free. It doesn’t contain any word about software bill of materials (BOM). There are bunch of quite useful information about value proposition behind ALM. I was looking for something that can hint how we can have unified product lifecycle and representaiton of information between Product Link and Integrity. Here is what I found.

PTC Integrity has an open architecture that integrates disparate tools into a streamlined engineering process, allowing orchestration of engineering change and collaboration across the technology supply chain. With PTC Integrity, engineering teams improve productivity and quality, streamline compliance, and gain complete product visibility, which ultimately drive more innovative products into the market.

Unfortunately, it doesn’t say much about combined BOM usage.

What is my conclusion? I wonder if manufacturers are interested to have unified product lifecycle management for both (more traditional) mechanical and electro-mechanical parts combined together with software bill of material. From traceability and completeness standpoint it sounds reasonable and logical to me. However, open publications didn’t bring much examples of such usage. Just my thoughts. I’m looking forward to discuss it online.

Best, Oleg


Follow

Get every new post delivered to your Inbox.

Join 285 other followers