PLM and ALM trajectories – integrated system development

November 16, 2015


More than 10 years ago, I had a conversation with one of telecom manufacturing companies in Europe. I asked – how do you manage to put a right software version in a telecom equipment company was manufacturing. The answer was shocking – we don’t know. It happens “automagically”.

It is hopefully not a case today. We can see software everywhere these days. Modern products are not mechanical devices. In many cases, it is a huge computer. Think about Tesla Model S, which is according to Elon Musk is a computer on wheels. We can even see how software features become actually “features” that people are buying.

In addition to that, software become an important part of business for manufacturing companies. We can see many devices that actually “enabling” software subscriptions for manufacturers. Also, there are hardware devices that completely dependent on selling software services.

Software is also a source of potential danger. Because of high dependencies on software, wireless and mobile connectivity, software can introduce a potential danger and way to hack any device (including your car on the road). This is a source of concern for many manufacturers these days.

So, software is eating the manufacturing world. The question how does it impact product development and manufacturing processes and software?

Few of my earlier blogs on this topic to catch up – The importance of software BoM for hardware security and How to combine engineering and software BoMs.

One of the fundamental things in PLM today is the ability to manage multi-disciplinary data. It comes to mechanical parts, electrical and electronics and software. All together, it is a system with a specific behavior. To model it will become a next challenge for manufacturers and an opportunity for software developers.

In my view, the domains of PLM (product lifecycle management) and ALM (application lifecycle management) are gravitating towards common system modeling, which can allow engineers using the best tool for product development, but control system behavior and component lifecycle in a unified way.

Last, week, I had a chance to speak at webinar by Polarion software. You can watch webinar recording here – The Internet of Things (IoT) and Good Software. Polarion is an example of ALM tool providers. The question how ALM and PLM tools can be integrated is the most important one. Both PLM and ALM vendors are looking for the answer.

For the references, below my slides from the webinar.

What is my conclusion? The role of software in manufacturing is increasing everyday. Modern cars are “computers on wheels”. We have embedded computers everywhere these days. Product features are defined by software as well as our security can be at risk in a new “hardware enabled software”. The integration of PLM and ALM tools into a system that can model product behavior is an important problem manufacturing companies will have to solve sooner than later. This is a note to PLM / ALM architects and software developers. Just my thoughts…

Best, Oleg

Common product lifecycle between hardware and software

October 15, 2015


Software is eating the the world. The phrase attributed to Marc Andreessen, American entrepreneur, investor, and software engineer. While it is a true in general it might have an interesting impact on manufacturing and product lifecycle software.

Software became an essential element of every product manufactured today. The examples are coming from all manufacturing industries. Take, for example, the last PCMag video from CES – Cars Are Becoming Gadgets With Wheels. Recent Tesla autopilot function was delivered as a software package – so called Tesla Version 7 software.

The importance of software in new hardware products developed by startups is growing too. Snapmunk blog – Pretty Soon All Hardware Startups Will Be Software Startups, makes a pretty strong claim towards the role of software in new hardware projects with example from Jawbone, NeuroOn and others. And one of the main reasons – business differentiation.

One of the main reasons hardware companies eventually gravitate towards software is that physical devices are prone to commoditization. Over time, it becomes increasingly challenging for any brand producing physical goods to differentiate itself from competitors. Earlier, the only way to stand out was by lowering prices.Now, businesses have the option of distinguishing themselves with the kind of software they offer in conjunction with their devices.

So, what PLM vendors should do about it? And what are customer demands?

PLM origins are mechanical CAD and it has little to do with software. For long time, PLM products didn’t do much about software. It was software configuration management (SCM) role to manage software versions and data. Later one ALM (Application Lifecycle Management) discipline has emerged – Application lifecycle management (ALM) is the product lifecycle management (governance, development, and maintenance) of computer programs.

Conceptually, functionality of PLM and ALM are overlapping. But from a practical standpoint and because of integration with different tools and packages are traditionally separate.

There are multiple use cases that can lead us to to think about future convergence between PLM and ALM tools. One of them is the need to manage multi-disciplinary bill of material including mechanical, electronic and software elements.

However, the reality in organizations is defined by people. And software engineers have their own preferences in terms of what tools to use and how. I can hardly imagine software engineers are moving from GitHub to some PLM-ish environments. The same can be said about mechanical and electronic engineers – they are using their own tools.

PLM vendors are stepping into ALM world via acquisition, investment and development. PTC acquired MKS back in 2011 and keeps Integrity is a separate product line within PTC portfolio of products. Siemens PLM made an investment in Polarion Software maker of ALM software. Aras recently announced an extension of ALM integration to connect with software world. I’m sure there are more examples.

What is my conclusion? You cannot stop the software. The complexity of software in manufacturing will increase and products will demand a more deep integration into product development process and lifecycle. It will be hard for manufacturing companies to keep software teams in a silo. So, better integration between software and other elements of product data will be demanded. Something PLM and ALM vendors should think about together. Just my thoughts…

Best, Oleg

Will PLM and ALM prevent a car from being hacked?

July 23, 2015


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


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


Get every new post delivered to your Inbox.

Join 287 other followers