The bathwater, usually dirty after the baby is washed, represents the flawed or obsolete parts that are best discarded—much like the parts of an idea or project that can’t be reused. The baby, on the other hand, is the part that retains value and is worth preserving.

In real life and business, it’s wasteful to do otherwise. This is especially true among manufacturing companies that invest heavily in process authoring to streamline the delivery of complex products and systems across multiple engineering disciplines.

Being able to repeat, measure and improve processes is a big advantage in an environment where manufacturers are under constant pressure to incorporate new and better features into their software-driven products and devices. But this can be challenging when intricate, systems engineering and software development processes are recorded in static, more traditional ways — such as thick, printed documents or on complex intranet sites.

Authoring, researching and fine-tuning processes captured in rigid formats like paper or a restricted network is expensive, not to mention, time-consuming. A project manager is more likely to ‘throw the baby out with the bath water,’ than devote too much time and resources to rejiggering a process that can’t be reused in its entirety.

Even when an existing process is relevant to a new project, ramp-up time for the engineers that need to use it is often longer with manual and static systems. Ensuring consistency can be hard, too.

PTC is in the business of helping manufacturers avoid these inefficiencies. Its focus is enabling the implementation of best practices through dynamic systems engineering processes that optimize time-to-market as well as product performance and quality.

Flexible and efficient process authoring, management, deployment and reuse are one important facet of systems engineering best practices. The PTC Integrity Process Director tool is an example of PTC’s leadership this area.

What makes the PTC approach to process development unique is its emphasis on two things. The first is ease-of-use, both from a process authoring and process execution perspective. This is significant, because where many processing authoring tools fall short is in the area consumption. If you can’t use it, why write it?

The second point of distinction is that of continuous improvement. To this end, Process Director gathers metrics and metadata and provides analytics and reporting tools. So project managers can evaluate how processes are applied and make enhancements over time. This is called “closing the loop,” emphasizing that what can’t be measured can’t be improved.

It’s worth going into some detail on Process Director’s ease-of-use advantages. To a large extent, it’s a function of the solution’s web-based delivery environment, which is built to scale and offers a high-performance database for managing not only processes, but also the context behind them. These can be graphics, videos — even detailed descriptions of who should execute which tasks and under what risks. Fully automatic and animated process diagramming uniquely improve process communication, understanding and buy in.

It’s also a function of the tool’s rich feature set, which enables authors, engineers and project managers to perform many tasks using convenient, drag-and-drop actions and graphic wizards. These simplify a number of complex activities — like configuring processes and tailoring them to specific projects, to name a couple. ‘To Do’ lists, email notifications, active mentoring and progress tracking keep processes on target and make them easy to use by engineers.

Manufacturers can save up to 45% on new project start-up time and 40% on user training and mentoring costs. One PTC customer, a France-based aero engine manufacturer, is finding this to be a huge advantage in an initiative to grow its systems engineering team, because it frees process authors and experienced users to move on to other projects as new hires come up to speed.

By building choice and logic into the discipline of creating, using and managing processes, PTC gives manufacturers the flexibility to sustain the value of ideas and practices that have already proven their worth.

The world of smart connected products moves fast. In this environment, manufacturers can’t afford to ‘throw the baby out with bath water,’ or ‘reinvent the wheel’ every time it initiates a new project.

Read this datasheet to learn more how PTC Integrity Process Director enables manufacturers to avoid this kind of waste.

The concept makes a lot of sense to manufacturers that build “smart” complex systems from multiple sub-systems and software components. A supplier of electronic dashboards for different automotive companies is a good example.

Although some dashboard features will vary based on make and model of the car, there are many common processes and components that can be reused or shared across all. Recreating every element to modify the dashboard design for every car brand would be inefficient and a waste of time and resources.

Does a strategy to avoid reinventing the wheel run counter to the value of innovating or thinking out of the box? No, of course not.

Manufacturers have and always will need to differentiate to achieve a competitive advantage. This is especially vital in an environment where the pervasiveness of smart, connected products requires manufacturers to shift their focus from the functionality of a single product to the performance of a broader product system.

In the manufacturing world, this is what we call a “system of systems.” Like the electronic dashboard of a car, which is built by plugging together a multitude of smart, connected devices such as a sound system, temperature and fuel gauges, speedometer and various other features.

To the automobile companies installing the dashboard in their car models, quality is measured by the performance of the complete, interconnected product—not any one component in isolation. This is the standard by which suppliers are judged.

An article from the Harvard Business Review, “How Smart, Connected Products are Transforming Competition,” explores in detail how the changing nature of products as systems of systems is pushing companies to rethink and retool internal processes. The authors call for a redefinition of the concept of operational effectiveness (OE). The cornerstone of competitive advantage, OE is all about doing things well. In other words, operating at a lower cost than rivals.

The authors, Michael E. Porter and James E. Heppelmann, warn that companies that fail to be operationally effective and constantly embrace new best practices will fall behind competitors in cost and quality. But when you assume that competitors eventually implement the same best practices and catch up, companies also need to consider strategic positioning.

In contrast to OE, which emphasizes doing things well, strategic positioning is about doing things differently. It’s a strategy that requires trade-offs in the context of deciding not only what to do, but also what not to do. The implications on product design are many. In their article, Porter and Heppelmann list several.

These include designs that support ongoing product upgrades, and product development processes that can quickly and efficiently enable late-stage and post-purchase design changes. Another is synchronizing different hardware and software development rates, which is crucial when you consider that a software development team may create 10 times as many iterations of an application in the time it takes to generate one new version of the hardware on which it runs.

Building these capabilities into product designs is where the practice of reusing and sharing software components and processes can add value. The faster the rate of change and the higher the demand to innovate, the more there is to gain from reusing public assets that satisfy specific design requirements—whether it’s the flexibility to replace parts easily mid-product-lifecycle, or use an anti-lock braking system designed for one car model in another.

Product engineering teams that identify places for reuse early in the product development lifecycle stand to achieve the biggest advantages. These include improvements in cost savings and time to market, which tie directly into OE, as well as product performance, reliability and safety, which define a manufacturer’s strategic position.

PTC recently enhanced its application lifecycle management solution with a repository and web browser for storing, finding and leveraging reusable system assets in model-based development. Called the PTC Integrity Asset Library, it gives product engineering teams common, widely-understood ways to manage and reuse public assets.

Public assets in this context can be any number of things; including specifications for future product concepts or fully executable components, defined as a “black boxes,” complete with code, hardware and user interfaces. Black boxes are especially useful to manufacturers that use component-based development to design systems of systems for two main reasons:

1) They can be easily plugged together with other sub-systems to create a design for a higher level system.
2) They can be changed to allow for variations in product design and improvements in functionality.

I call it “designing the way you build,” using a palette of reusable, interchangeable components to create a whole. By changing the focus from the product to the system level, the PTC approach helps manufacturers optimize OE and strategic position by allowing them to make the most of existing resources. And make smart choices about where and how to differentiate. It’s like “seeing the forest for the trees,” which is important to manufacturers that need to focus their time and talent on innovations that generate the highest returns.

Click here to learn more about the PTC Integrity Asset Library and how it saves product engineering teams the time and cost of reinventing the wheel on every component of every design.

To learn more about how the changing nature of products is impacting manufacturing, read the Harvard Business Review article, “How Smart, Connected Products are Transforming Competition.”

Manufacturers thus find themselves at the nexus of exploding product variants, rising costs, and reduced development cycles. It’s useful to ask ourselves, how did we get here?  What are the implications?  And how are leaders responding to these market forces?

First let’s look at the macro-economic forces driving this transition. In the past, product differentiation was primarily achieved through mechanical and electronic innovations. Today, however, manufacturers frequently use software to drive the user experience. For example, today’s automobiles contain more computer chips and lines of software code than the first vehicles launched into space. Presently software and electronics account for about 25 percent of a vehicle’s value and that figure is expected to climb to 40 percent or more in the next 5 to 10 years. Similar trends are occurring in a wide range of industries such as medical devices, appliances, consumer electronics, heavy equipment, machinery, etc. Every change in the function of the software used to operate each sensor, actuator or processor introduces, in essence, a new product variant. The result is a dramatic increase in product variability which involves not only creating a new design but also managing the requirements, testing, documentation, maintenance, etc. of the variant.

What are the implications of this evolution towards software-intensive products? Consider that many tools are available for handling different aspects of the design process for mechanical, electronic and software components. The challenge is that companies are typically managing each component with disconnected systems that require manual transfer of information from one to another. This results in extra work and bottlenecks that can impede the development process. Also important to note is that most manufacturers have more mature methods for managing the mechanical aspects of product variability, typically through computer aided design systems. Variations of the increasingly important electronic and software components often handled with spreadsheets.

How are market leaders addressing these challenges? Manufacturers are increasingly investing in the development of common platforms that enable re-use of requirements, designs, components, tests, etc. to support fast and economical release of product variants.

The integration of Application Lifecycle Management (ALM) with Product Lifecycle Management (PLM) makes it possible to manage mechanical, electrical and software variability in a single cohesive platform. This enables companies to address variability at the systems engineering level at a much earlier stage of the development process, when the product architecture is being defined. For example, a manufacturer of off highway vehicles could establish requirements for and design a braking system with a common architecture and components that could be re-used across a wide range of vehicles. Not just the mechanical aspects of the design but also the software and electronics can be seamlessly integrated so that each requirement and block of code is allocated to the product variant and its requirements. Visibility and control spanning ALM and PLM assets enables companies to manage and propagate changes in a controlled manner across product families.

Let’s explore how variant management works in practice. Users typically start by writing a set of base requirements that are common for all functional variants of the product. Each product variant points to these base requirements, which eliminates the need to have a new physical copy and keeps the variants in sync with the common requirements. Once the common base is certified, it does not need to be re-certified every time a new variant points to it. Only the requirements unique to the variant need to be certified. Likewise when the common base changes, it only needs to be recertified once as opposed to once per variant. Significant savings in time and cost occur if a change request targets something in the common requirements. In this case, the change is made only once rather than in many copies of the common base. The changes are saved in a new version of the common base. Future variants can point to this new version but current variants will not automatically point to the new version. This preserves the certification that was conducted for each of the current variants.

Manufacturers can reduce the difficulty of managing increasing product complexity by implementing a systems engineering approach that makes it possible to architect products for commonality and re-use. At PTC, we have optimized the Integrity ALM solution to support easy and quick releases of variable products. Specifically, we’ve designed a solution that supports an advanced – and parameterized — re-use paradigm that efficiently isolates changes and ensures full traceability across the variant lifecycle. By replacing costly and complex “clone and copy” models with an efficient alternative, manufacturers can speed product development cycles, lower costs, and more efficiently deliver the right products to the right market.

Learn more about the PTC Systems Engineering Solution. 

Many manufacturers are already seeing the benefits of IoT and having that closed-loop product development. For example, companies like Alstom Transport, AVL and Barco are able to do predictive maintenance; they are able to detect problems before they affect the user. The ability to service products, to make changes across the Internet and update software is a major benefit to these companies. Of course there is also a safety critical dimension that adds complexity when developing these smart products. You have to ensure that the process of making changes will adhere to compliance standards, and that there is a defined pipeline where all the testing is done and the certification and so on.

With a model-based systems engineering approach, you can build that, you can automate a lot of those processes. This will enable that fast feedback, that fast change to take place, reacting to problems in the field and being able to prevent a failure in the field. That information about those issues can then feed through not just to correct the problem, but also prevent it in the future. Those fixes may also feed back into the manufacturing process, or it might even go further back into the design and development stage. Enabling all of these feedback paths is a tremendous benefit to having smart, connected products and systems.

This is why systems engineering for smart, connected products is so important. As you can see in the Product Line Engineering (PLE) infographic, a study by analyst firm EMF shows that a model-based approach to product line engineering delivers 23% more projects on time; at 62% lower cost, than alternatives, based on a survey of 667 engineers.

Michael Azoff and Tony Baer, principal analysts with Ovum have authored this paper entitled ALM for Engineering Products, they state that, “Embedded software and hardware manufacturing is both architecture- and requirements-driven, and organizations that invest in improving their maturity in these two disciplines will reap the rewards of faster cycle times and improved product quality.”

Related Resources
PTC-Ovum Systems Engineering Webcast Series
PTC Systems Engineering Resource Center

Photo courtesy of Alstom.

PTC/USER Technical Committees are composed of volunteers from the PTC/USER membership, who work closely with PTC’s Product Managers (PLMs) to direct future software development.  Participating in the Technical Committees is the best way to influence the development of PTC software. Technical Committee participation provides you with:

• Direct interaction with PTC Product Managers, and other key PTC personnel
• The ability to influence PTC’s software plans and specifications
• The ability to evaluate software before the F000 release
• Regular information exchange with other Technical Committee members

I am actively recruiting members who want to influence the future of the Integrity family of products and meet the following expectations:

• Each member must have experience with at least one of the Integrity products so that they can provide meaningful insight to PTC’s product development efforts.
• Each member company must be using at least one of the Integrity products in a production environment active maintenance contract.
• Members and their company must commit to active participation in the Integrity Technical Committee, including attendance of the face-to-face meeting(s), participation in webcasts, give presentations to other Integrity TC members and PTC, participation in specification reviews, and development of whitepapers

If you are considering joining, I ask that you do so by Wednesday, April 8, 2015 in order influence the date, time and location of our inaugural meeting in June.

To join the Integrity TC:

1. Join PTC/USER
2. “Request to Join” the Integrity TC

Thank You,

Paul Hartwig
Integrity Technical Committee Chairman
Paul_Hartwig@irco.com

They look to PTC for solutions that help manage the complexity. Many use PTC’s Integrity Lifecycle Manager ALM (application lifecycle management) platform to support agile product design processes.

PTC Integrity Lifecycle Manager gives manufacturers a holistic, tool-agnostic way to change-manage all the assets that comprise a system, system of systems or connectivity between systems. In doing so, it simplifies hardware and software integration; and also streamlines collaboration across product lines as well as software, electrical and mechanical engineering roles.

PTC is constantly building on the capabilities of PTC Integrity Lifecycle Manager to enable manufacturers to improve these methodologies to control costs and be first to market with the advanced, software-driven features and conveniences customers want. I recently got some insight on the latest and most significant of these enhancements from PTC Vice President of Product Management, Doug Akers.

Our talk centered on improvements that debuted last fall in PTC Integrity Lifecycle Manager v. 10.6 and will be extended this spring in version 10.7 and subsequent releases. Here are highlights from our conversation:

Karen:  Let’s start with the big picture. What factors make the design and delivery of smart connected products more complex than products built with mostly mechanical components?

Doug:  Building and releasing products made up of multiple systems and subsystems requires lots of code, lots of parts, and lots of people and partners across different business and engineering functions. All of this increases the potential for production bottlenecks and missteps that can affect schedules, quality and cost. Time is also a factor. The pressure to frequently push out new, more sophisticated features and functions is a constant.

Karen:  What product design capabilities do PTC manufacturing customers look for to address these complexities?

Doug:  Top priorities are maximizing developer productivity; reusing product development assets in smarter ways; and fully integrating all aspects of engineering to achieve what we call “continuous integration and release.” These are the factors that most impact cost, time to market, as well as product quality and performance.

Karen:  How do these priorities fit into the PTC Integrity Lifecycle Manager product roadmap?

Doug:  They drive it. The latest enhancements in v. 10.6, and the new capabilities scheduled for release this spring in v. 10.7, are specifically designed to help our customers meet these priorities.

Karen:   What are the most notable, new features in PTC Integrity Lifecycle Manager?

Doug:  PTC Integrity Lifecycle Manager v. 10.6 features a number of new configuration management capabilities like time-based viewing and retrieval of source code and requirements. Other highlights are support for systems-based modeling through our recent acquisition of Atego; and performance and scalability improvements for end-users across the product lifecycle—from developers to systems engineers to business analysts.

Karen:  Describe briefly how the configuration management improvements introduced in PTC Integrity Lifecycle Manager v. 10.6 drive many of the gains achieved through continuous integration and higher productivity.

Doug:  PTC Integrity Lifecycle Manager v. 10.6 provides the ability to access, version, baseline and submit changes to requirements, test and other assets as one logical change — like has been done with source code for decades. This helps collaborators in different roles work more efficiently by raising the abstraction level of complex tasks. It also simplifies authoring and comparing versions of authored assets.

Karen:  Give an example of how a PTC manufacturing customer is implementing the latest PTC Integrity Lifecycle Manager enhancements to achieve a specific, tactical goal.

Doug:  HUAWEI, a large global provider of connectivity devices and technology, is an example of a customer that’s implementing continuous integration and delivery to do more with the same amount of resources in less time. They perform software builds on an incredibly frequent basis, but don’t always want to identify them up front as a meaningful baseline within the repository.  We’re working with them to implement new, time-based SCM capabilities that enable continuous access to any software configuration at any time—even configurations that are never progressed in the lifecycle. They can go “back in time” to baseline configurations, those that pass all build and validation processes, when that configuration becomes meaningful. We’re also helping them integrate new functionality to support private operations and better manage of work in progress.

Karen:   How do the latest and upcoming releases of PTC Integrity Lifecycle Manager address manufacturers’ cost and productivity challenges.

Doug:  The bigger data repositories grow, the more costly they are to manage. Because not every change to an asset requires promotion to the repository, we’ve made a number of improvements to enable users to work more productively with data residing in the file system. These include support for storing and viewing bulk data in file systems and better allocation management tools. The goal is to make sure all contributors can work with code in a meaningful way without cluttering the repository — whether in isolation or in collaboration.

Karen:  Beyond this spring, what will be the focus of future enhancements to the PTC Integrity Lifecycle Manager ALM solution?

Doug:   Going forward, our plan is to really focus on the needs of software engineers to help them better execute every-day tasks.  Expect to see continued refinement of bulk operations, enhanced commands and utilities, and change and configuration management capabilities. Our priority is making sure that the improvements we make to PTC Integrity Lifecycle Manager and all PTC solutions are in lockstep with customer needs to do more, faster, with less.

For more information on PTC Integrity Lifecycle Manager, visit: PTC.com/go/Integrity

These efforts are a big shift for manufacturers accustomed to producing discreet, stand-alone products to meet specific sets of needs. Demand for smart, connected products is pushing manufacturers to retool internal processes. It’s also expanding the scope of “product line engineering” to encompass portfolios of related products that leverage common components to simplify customization.

I recently had an opportunity to talk with Derek about product line engineering (PLE), and how PTC helps manufacturing customers use PLE best practices to deliver better products more efficiently. Here’s a summary of our conversation:

Karen:  Let’s start with the basics. What is product line engineering?

Derek:  Initially, the term, “product line engineering,” was used to describe the process of building product variability through software. But in recent years, manufacturers have begun using it to more broadly define products that are designed with elements of variability and modularity.

Karen:  Can you give specific examples?

Derek:  Volkswagen has come up with a new platform for designing standard base frames that can be leveraged across all its vehicle models—such as Passat, Jetta and Golf. So instead of building a discreet engine for each product line, they design it modularly so it can be easily configured based on different feature packages. In respect to smart connected products, cell phones are a great example. Users can constantly reconfigure the software that powers their apps and communication functions. But they may carry around the same, physical phone for several years.

Karen:  Describe the connection between PLE and the need of manufacturers to shift from building discreet products to “systems of systems.”

Derek: Historically, product line engineering involved defining a set of requirements, building a product to meet the requirements, and then making discreet modifications to individual products when a change was necessary. Now that manufacturers are designing products to be parts of systems of systems, they’re taking a more holistic approach to answer questions like: “How do we differentiate products to suit varying customer demands without rejiggering everything?” Or, “How can we use the Cloud to deliver new features and enhancements on demand? “ Doing any of these things cost effectively requires the ability to share and reuse processes, ideas and components across families of products. That’s what 2^nd generation PLE is all about.

Karen:  In what ways are PTC customers implementing PLE?

Derek:  PTC has many customers that are early adopters of PLE. Most implement it in one of two ways: In a physical sense or in the abstract. An example of a customer implementing PLE in the physical domain is a truck manufacturer that uses our CAD software to design every possible configuration of specific vehicle features—like the height of the door or wheel, or size of the cab. No two trucks are alike.

Customers that use PLE in the abstract think about modularity and variability at the backend, identifying standard components that can be shared across the entire product line. Then designing these standard components in ways that make them easy to configure.  Like Volkswagen, for example, that designs one engine for all car models and then fine tunes it based on horsepower. We call this front end PLE, which is where most PTC customers are moving towards.

Karen:  What are some challenges facing manufactures that use PLE to design smart, connected products or systems of systems?

Derek: Manufacturers today are often developing smart, connected products with thousands and thousands of configurations. It’s virtually impossible to test every configuration in every context; which makes risk management in terms of simulation and validation a big challenge.

Karen: How does PTC help customers address these risks?

Derek: With our acquisition of Atego last summer, we now offer a true, complete PLE solution that enables manufacturers to design modularity and variability into their systems upfront and close the loop between requirements and traceability. This alleviates much of the pain and cost of dealing with problems after delivery by identifying environmental and contextual risk factors early in the product development lifecycle. We’ve enhanced a solution focused on requirements and verification to also provide advanced, model-based PLE capabilities.

Karen: How does your work in the PLE sphere support PTC’s overall objective to help manufacturers do what they do, better?

Derek:  Although PLE is common practice for many PTC customers and early adopters; it’s still a goal for others looking to take the first step. Some want to start with requirements management. Others are more focused on test management.

Our job is to help manufacturers find the best approach for delivering better products more effectively. With model-based PLE, there are many places to start.

Learn more about how the new PTC Systems Engineering solution supports product line engineering.

Despite these dismal statistics, demand for “smart” technology in cars – as well as and other devices with safety-critical components like insulin pumps, pacemakers and home heating systems — is continuing to rise. It will keep climbing as microprocessors become more powerful, and consumers develop bigger appetites for the perks and conveniences of smart technology.

This brings new challenges to manufacturers of automobiles, aircraft, medical devices and other products that need to function predictably and be understood by customers to protect life and property.

In this post, we look at how the preponderance of embedded software in safety-critical systems is changing perceptions of quality and manufacturers’ approaches to delivering it.

Consumer products have always featured safety-critical components. When they were mechanical or physical, identifying and testing potential causes of failure was a straightforward engineering function. Safety was closely linked to the reliability of the component, which manufacturers could qualify based on proven patterns of wear and tear. Assessing software’s impact on safety is more complicated.

With cars, the challenge stems from ever-growing volumes of embedded software, as well as from the complexity of the operations the software controls. Today’s late-model cars are essentially high-tech devices on wheels.

A luxury car contains about 100 million lines of code and 20 million controls the navigation system alone.

Embedded software also controls brakes and complex cruise control systems that use cameras and sensors to adapt speed to changing road conditions. In some car models, embedded software operates as many as 11 airbags that have to deploy at exactly the right moment to protect everything from head to knees.

The more variations, the more difficult it is to predict its behavior in every possible situation.

Another complication is that software-driven safety components rarely function in isolation. A driver’s behavior can impact the performance of the airbag. The ways in which a nurse interacts with the interface of an electronic infusion pump affects dosage rates. Components can fail when users don’t invoke the software that controls them in a predictable manner.

With so many unknowns being compounded by by rising budget and first-to-market pressures, manufacturers recognize that they can no longer sustain the exhaustive testing needed to identify every possible cause of failure.

Still, they have a responsibility to mitigate and minimize product safety risks and alert customers of potential hazards. (Otherwise, we wouldn’t be talking about this year’s record number of auto safety recalls.)

To bridge these competing realities, new safety standards such as ISO 26263 for auto manufacturers have emerged to guide a smarter approach to product development and testing. Based on risk, these industry-specific standards associate testing requirements to a component’s impact on safety.

In the case of a car, a DVD player is classified as a low-risk component; navigation system, moderate; electronic brakes, high. The rigor of testing and process control applied to each component is tied to the severity of the consequences should it fail.

The adoption of risk-based safety standards shifts the focus of product development from preventing failure to protecting safety. This challenges manufacturers to rethink the long-held idea that quality and reliability are one and the same.

It adds a whole new dimension to the development lifecycle by expanding the scope of requirements gathering to include hazard analysis and product functionality.

The overriding goal of a hazard analysis is to identify and design ways to mitigate risk. The approach is to gain a full grasp of the various environmental, user- and process-related factors that contribute to these risks.

This analysis informs design decisions not only for software, but also for the protective hardware and labeling that can reduce the impact or instances of harm. It also blurs the lines between software, hardware and systems engineering teams that need to understand the effects of change and the impact of design decisions on overall product safety.

For manufacturers, this means adopting agile product development practices to support seamless cross-discipline collaboration, integrate hardware and software, manage software variants across product lines and streamline regulatory approvals.

By investing in ALM, many manufacturers are benefiting from improved traceability enabled by effective process control. This is especially vital to teams that develop software for safety-critical systems with a large number of variations—like a supplier of electronic braking systems to multiple automotive OEMs.

Tracing and correcting problems that are a potential safety risk before products are released is a smart move. I’m sure that’s the new attitude of the automakers behind this year’s safety recalls.

Learn more about PTC’s ALM Solutions. 

The challenges faced by today’s discrete manufacturers really highlight the need for improving on existing methods for how they do business. The continual growth of product complexity, more distributed design teams, and the pressure to release more products on-time with better quality at lower cost have all put significant pressures on current engineering processes and approaches. Our customers look to us to provide new solutions to help them deliver their best products.

I know that the PTC Systems Engineering Solution, whose release is being announced this week at the PTC Live event in Stuttgart, Germany, will help our customers address many of these needs.

The solution helps organizations:

• Design more innovative products using a collaborative, model-based systems engineering approach
• Reuse systems artifacts to enable profitable product line engineering
• Validate products meet requirements and best practice processes are followed

The PTC Systems Engineering Solution combines the PTC System Requirements and Validation Solution with the functionality recently acquired (June 2014) from Atego. This brings together leading capabilities in model-based systems engineering (MBSE), requirements engineering, test/validation management, and product-line modeling.

I’d like to describe a little bit of each portion of the solution (Design, Reuse, and Validate) to give you a sense of what the solution has to offer.

In Design, we focus on the systems design process which covers:

• Capturing and managing the complete system and product requirements
• Collaboratively designing the system specification using standard modeling notations
• Analyzing the design options to define the functional areas of the entire product

For Reuse, product line engineering is the main topic implement by:

• Reusing all requirements, models, and tests across design projects or products
• Architecting a modular system or system of systems design which can be reused
• Designing a family of sub-systems which includes both commonality and variation

To Validate, the product we handle this through:

• Automating the design (both models and requirements) review process early on
• Capturing and managing the test cases and related test results
• Capturing and visualizing traceability across the design artifacts
• Utilizing systems engineering best practices for compliance and governance

I am excited about the entire offering we can provide to our customers. Today, PTC is the only PLM vendor that brings together system requirements, system modeling and validation. It’s only through this end-to-end approach that customers can scale their product and product line engineering practices to meet the systems engineering challenges of today and tomorrow. I know what we have defined will help address our customer’s needs.

Learn more about the PTC Systems Engineering Solution. 

Related Articles

• What Can We Learn from Systems Engineering Failures?

The Agile movement has revolutionized software development, in large part by its focus on getting teams of software developers to work together more effectively. The basic idea of Agile development is that software should be delivered incrementally, in easily digestible chunks. This in turn encourages early feedback so that requirements can continue to evolve as development proceeds, maximizing value to the customer.

The Agile approach was originally designed for very small, self-sufficient teams working in close proximity to each other. Not surprisingly, implementing an Agile transformation in an enterprise environment is much more challenging. Large and geographically distributed teams are often needed to produce the complex solutions required by enterprises. The team gets even more complicated when contractors, partners, customers or suppliers are involved in the project.

Enterprise development teams are often subject to additional scaling factors, such as regulatory compliance, domain complexity and technical complexity. When we go about implementing Agile processes in larger organizations, we need to assess where the company stands with regards to these scaling factors, and implement processes and tools to address them.

Large teams utilizing Agile processes need to share information as easily as if they were working in adjacent workspaces. Communications tools such as videoconferencing, white boards and instant messaging can make it easier for large and dispersed teams to communicate. It’s also important to provide a tool to manage access to artifacts such as requirements documents or user stories. Tip: It often helps to organize teams so that members are in similar time zones, and to alternate meeting times so that the pain of having meetings outside normal working hours is equitably shared.

Agile is modelled around self-organization, which makes it particularly important to address the cultural differences that arise among enterprise “teams of teams.” When multiple organizations are involved in a project, each of the organizations tends to have its own, sometimes conflicting, objectives, culture, and organizational structure. In my experience, the best way to break down these silos is by creating opportunities for cross-group integration and transparency. Establishing cross-organizational groups at the senior level as well as in key functional specialties helps foster a clear understanding of team roles and a greater appreciation of each team’s distinct strengths and capabilities.

For most of our customers, regulatory compliance plays a critical role in enterprise software development. For example, FDA Title 21 CFR Part 11 requires drug makers and other FDA-regulated industries to implement controls for software and systems that are involved in processing data that is required by FDA rules or used to demonstrate compliance to FDA rules.

I can’t stress enough: Compliance needs to be baked into the process in the leanest way possible. Most development organizations tackle a wide range of projects, and not all of these projects require the same degree of rigor. In one enterprise Agile transformation, we created decision matrices to determine what level of rigor was required for each project. For example, on a high risk project the team might be required to create a detailed design for management approval while on a low risk project it could make design decisions on its own. This is an area where our own ALM tool, PTC Integrity, really shines, as it allows you to quickly customize any team process and easily transform it into an executable Agile workflow.

Two additional challenges that are often present in enterprise software development are domain complexity – complexity of the field in which the solution operates – and technical complexity – complexity in the way the solution works. Let’s look at each in turn.

Domain complexity is addressed by engaging experts in the same discipline as the end users of the software – such as engineers, doctors or bankers – into the development process. For example, PTC Creo is tested by mechanical engineers who know how to design complex products that exercise the software to its fullest extent. Learning mechanisms such as Communities of Practice can be created to make better use of the subject matter experts within the organization.

Technical complexity, requires frequent integration and early testing which are, interestingly, the core tenets of Agile transformation. I once worked on the Agile transformation of a team responsible for delivering a project that involved Java, C#, and a proprietary development language. We kept the project on track by creating a new build every day that ensured integration of each of the technologies.

Disciplined Agile Delivery (DAD) is a recent Agile software development approach that can aid in the transformation of enterprise development teams. DAD extends the construction-focused methodology of Agile development to address the complete end-to-end delivery cycle from the initiation of the project to the delivery of the completed solution to the customer. DAD goes beyond producing potentially shippable software to producing consumable solutions that solve business needs.

In the end, Agile development requires changes in culture and attitude as well as changes in tooling and process automation. For Agile development to succeed in the enterprise environment, developers need to stay true to their self-governing ethic as they work closely with enterprise professionals. They should also leverage enterprise assets. Achieving success means focusing on the right behavior and learning environment as well as the best process and toolset to enable Agile teams to act locally and develop globally.

Now let’s take a look at how manufacturers can embrace these technological advances to unlock new business opportunities and accelerate growth.

Manufacturers are beginning to understand that both software and connectivity are essential components to their product development lifecycle. Smart, connected products and the IoT open the door to true closed-loop lifecycle management where product information can be tracked, managed, controlled, and tightly integrated.

But the shift toward smart, connected products presents a unique set of challenges.

Engineering teams need to integrate mechanical, electrical and software components, global teams working across different disciplines, languages and systems must collaborate, outsourced development to suppliers or strategic partners needs to be managed and coordinated, and intellectual property (IP) needs to be protected.

To remain competitive, manufacturers must adopt lean and agile methodologies, support software product lines, manage variants and platform changes, streamline regulatory compliance, and improve software quality management processes.

The effort is well worthwhile. By investing in software development, manufacturers have seen some significant improvements in efficiency, profit, competitive edge, and even development times.

In a recent McKinsey & Company report, several companies improved their time to market by 30 to 40 percent by focusing on embedded software development, and a recent IBM executive report found that 69 percent of companies that leverage software development effectively outperform their competitors.

Learn more about how connected software is changing our world and how manufacturers are transforming their businesses.

Related Articles:

• Manufacturers Reshape for Smart-Product Future
• Software Critical to Smart-Products Manufacturing

New technologies, applications, and devices are spanning across all types of industries from aerospace and defense, agriculture, and automotive to high-tech, medical devices, and many more.

Did you know that there are 100 million lines of software code in a luxury car and that 20 million of that is in the navigation system of the vehicle? There are 12 million lines of code in an Android phone, which is twice that of a Boeing 787 at 6.5 million.

Here are some key milestones and predictions relating to embedded (connected) software:

• 1989 the Internet is born marking its 25^th year this year.
• 1993 first browser app launches: a number of browser applications are developed during the first two years of the Web, but it’s Mosaic, available for UNIX, the Commodore Amiga, Microsoft Windows and Mac OS, that has the most impact.
• 2000 the emergence of smart devices: Nextel aggressively expands its reach and product capabilities. By the year 2000 the company has connected to countries around the world and introduced its always-connected wireless data solution.
• 2013 the number of connected devices increases to 9 Billion. In this McKinsey Insight Report on disruptive technologies it is predicted to jump to 50 Billion by 2020 and to 1 Trillion by 2025.

Over the past decade products have evolved from being purely mechanical with electrical components to complex systems that are software-driven and connected to both public and private networks, and because of this discreet manufacturers are finding new ways to connect their products and transform the way said products are created, operated, and serviced.

Auto manufacturers who are required to comply with myriad safety standards, for instance, are adding more sensors to vehicles to capture or detect when a failure is about to occur. This allows the manufacturer to be proactive in making changes early on in the product lifecycle. An added bonus – they are well-prepared if and when a fix or patch needs to be applied to the final product.

In the very near future, most consumers will be able to download and apply a fix to a car defect instead of the auto-maker having to recall a fleet of vehicles (Tesla already offers this).

View this infographic to see how manufacturers must adapt to the explosion of software and networks or risk losing competitive advantage.

Look for part three of this blog series where we’ll take a look at how manufacturers are uncovering new value from smart, connected products.

Related Articles:

• Manufacturers Reshape for Smart-Product Future
• Recall Reveals Why Tesla Will Come Out Ahead

Products today are no longer just physical or mechanical; they often have sensors and mechanisms connected to the Internet and other smart devices. These smart products continually provide feedback and data into the cloud, giving manufacturers fresh insight so they can make improvements to next-generation product and fine-tune operations and service.

It is predicted that we’ll have 1 trillion connected devices by 2025. We have cell phones that are connected to home thermostats, implantable medical devices that help to monitor a person’s health, and sensors in vehicles warning us if we get too close to another car or obstacle. More connectivity enables greater product functionality, and future possibilities are endless.

A recent survey conducted on behalf of Wi-Fi Alliance shows that there is a surge of consumer interest in smart devices. Ninety-three percent of respondents said controlling the home remotely will have a positive impact on the quality of their daily lives. Seventy-seven percent believed Wi-Fi connectivity will be an important purchase consideration when replacing household items, and 63 percent expected that within 10 years the majority of devices or appliances they purchase will include smart technology.

According to Juniper Research, by 2018, the ‘smart home’ market will double in size reaching $71B – up from $33 billion in 2013 and $25 billion in 2012.

The demand for smarter products has created an explosion of smart connected software and networks. With all this “smartness” happening around us, what will the future look like for both manufacturer and consumer?

Check out this by-the-numbers infographic charting the journey of software-enabled innovation.

Stay tuned for part two of this three-part series in which I’ll outline the progression of technology and how the explosion of software has affected the growth of the Internet of Things (IoT).

Times have changed and so has technology, and software is at the heart of it all.

Today smart connected products and the Internet of Things (IoT) allow us to be connected to our kids, our homes, our workplace, and even our medical providers 24-7. The software is in our cars, mobile phones, pacemakers, and even household appliances makes this possible.

While smart connected products are useful and often fun for the consumer, they bring an even greater set of opportunities (and challenges) to the manufacturers.

Software, present in so many of the things we buy today, makes a product more complex. Because of this, engineering leaders are having to rethink their manufacturing processes and approaches to product development. Now when manufacturers look at product safety, quality and compliance they also need to factor in software.

It’s essential that software is managed appropriately, from proper treatment of product data to ensure compliance with industry standards, to traceability; any changes made within the software development phase must be tracked and managed effectively and efficiently.

A recent IDC Manufacturing Insights report presents the business transformation steps that manufacturers must take to support the development of increasingly complex products, especially those containing embedded software and electronics.

The report concludes that in this new software-intensive world adopting a systems-driven approach to product development is key. This should combine systems engineering with an integrated product definition, and allow for a way to define interdependencies and clearly communicate the impact of changes to the system.

Leveraging and integrating PLM and ALM tools and driving organizational and cultural change to bridge the gap between siloed engineering departments is also critical.

Register here for a live webcast from IDC analyst Melinda-Carol Ballou on the value and importance of managing software throughout product development.

So, what is this guy, a former U.S. World Bank chairman, doing at the Seattle ALM Forum addressing a group of software development professionals? And how did he manage to get himself sponsored by the Scrum Alliance, a non-profit organization known only to the geekiest of geeks?

Well, years ago, Denning, a then young, fresh-faced economist, asked an innocent question in a meeting with top executives. This was his first lesson in the power of “culture” within an organization. His question was shot down immediately. All other avenues of inquiry closed, with an abrupt “…and anyone who thinks otherwise is a poor fit for this organization.”

So began Denning’s extraordinary, decades-long exploration into the elements of organizational culture and change, a journey which includes multiple best-selling books, a distinguished career at the helm of the World Bank, and an unlikely yet oddly perfect association with the scrappy Scrum Alliance (he is on their Board of Directors.)

Scrum Alliance is a non-profit membership organization that encourages and supports the widespread adoption and effective practice of scrum, a specific set of Agile practices. A scrum—fashioned from the British rugby term—is a group of people who work together to accomplish a goal. In the realm of software development, the scrum works to deliver products in short cycles, enabling fast feedback and continual improvement.

Agile teams are all about self-organization, pushing down decision-making, and making teams self-governing. A wealth of literature attests to the efficacy of these practices for improving software development velocity and quality. Simply put, agile teams get more and better stuff done.

But over many years of studying organizational change paradigms, Denning has noticed a tension between some agile teams and the corporate environment in which they operate.

“Development organizations must reflect the environment in which they operate,” he explains. “A shift is taking place between the culture of creativity and the culture of command and control.”

At the organizational level, Denning says, the only thing that really matters is the ability to “delight your customer.” Organizations that focus single-handedly on this metric naturally align their business processes to maximize customer value. These companies create a virtuous cycle of delighting customers, empowering employees, and engaging employees with a more collaborative, conversational communication style. Revenues and profits inevitably follow.

On the other side are companies that focus primarily on the metric of returning share-holder value. According to Denning, these enterprises—and there are many—have been hoodwinked into confusing cause and effect. Instead of investing in business processes that surprise and delight their customers, they are caught in a vicious cycle of bureaucracy, control-based hierarchy, and a rigid, command-based communication style.

I ask Denning whether the pillars of the Tech 100 are too beholden to Wall Street to focus on anything but quarterly earnings. Do they really have a choice? Absolutely, says Denning. He mentions one tech giant that publicly announced its intention to change its business model from delivering products to delivering cloud services. That company made clear that quarterly earnings would go down in the short-term, as a result. Wall Street responded by increasing the company’s stock price even in the face of revenue declines.

According to Denning, having corporate goalposts like delighting customers and empowering employees makes all the difference in how organizations evolve their culture. These goals inform all decisions and actions. In the words of organizational change luminary Peter Drucker, “culture eats strategy for breakfast.”

Related Articles:

• Rapid Feedback, Why Your Software Team Needs It

It feels a bit like cheating—like ordering apple pie for dinner, or eating shelled pistachios—but I’m going to do it anyway.

The ALM Forum is a three-day gathering of software professionals dedicated to the dark arts of software lifecycle management. These are the project leaders, scrum masters, agile coaches and IT architects who care deeply about the meta-data of software development, and who live their professional lives at the intersection of software development and organizational change consulting.

As you can imagine, metrics are never in short supply at this conference. Pretty much every presentation—whether from Etsy, Bank of America, or Ancestry.com—usually involves at least one “before” and “after” chart that displays the impact of some stimulus—a change in process, tools or organizational structure—and often, a mix of all three.

So after three days of attending excellent presentations that included hundreds of metrics, here are my candidates for the only metrics that matter. They come in two categories: technology and (in my next post) organization.

First, technology. And folks, it’s all about reducing mean time to feedback, at least according to Steven Borg, a co-founder and principal ALM consultant of Northwest Cadence.

We all know what it’s like to solve a complex problem, whether it is solving a mathematical equation, building a new software feature, or resolving the form and function of a kitchen remodel.

When we are in the problem-solving zone, we study the problem, break it down into smaller, more manageable parts and even create models of the problem space. We are keenly aware of multiple levels of information, context and interdependencies.

But this deep contextual understanding comes with an expiration date. For most of us, our brains are just too porous to maintain this deep contextual knowledge after we’ve turned our attention to something else. That’s why there is such a huge difference between getting feedback in an hour, a week, or a month. If we get feedback when the problem is fresh in our mind, then we can quickly and efficiently respond.

If we get that feedback weeks later, it may as well have gone to a different person with no prior knowledge of the problem. Like the Bill Murray character in Groundhog Day, we are destined to painstakingly recreate our understanding of the problem all over again.

Multiply this by hundreds of discrete tasks and hand-offs, and you can quickly see how reducing mean time to feedback becomes a transformative organizational metric. According to Borg, teams that use mean time to feedback as their guiding principle will naturally evolve their organization over time to become more agile.

They will break the problem down into smaller vertical slices, fast-track internal feedback loops, automate testing, deployment and whatever else can be automated, deploy working solutions more quickly, and accelerate external feedback. It’s a North Star for any agile transformation.

From concept to delivery, the most important area to reduce mean time to feedback is (of course) customer validation. The quicker we can get prototypes or working software into the hands of our customers, the faster we can get feedback in time to make a difference in the marketplace.

Next, I’ll explore the only metric that matters for building high-performance organizations.

If you liked this article, please consider this your personal invitation to join us at PTC Live Global ALM Track and Forum, this June in Boston, where we’ll be exploring all things ALM, tuned to the unique needs of manufacturers.

In this blog entry, I’d like briefly expand on the significance of the integration concepts introduced by Juan in solving several key challenges of software-intensive systems engineering and product development and how engineering analysis and related practitioner tools, like Mathcad, will be used in new ways, in part thanks to deeper levels of integration with the rest of the practitioner tool set across the lifecycle.

Engineering analysis as a practice has been a core part of the systems engineering and complex system development from the beginning. Analysis methods are often employed beginning with the initial system or product concept to model, predict and specify system behavior. In design, analysis methods enable engineers to simulate behavior before building the first prototype and are then used to specify the behavior of the component as it’s developed. In the modern era, the behavior of an electronic component is most often implemented in embedded software, rather than with custom-built electronic circuits. It is precisely this transition from behavior implemented with custom electronics to implementation of much more complex behaviors in software that is driving engineers to employ analysis methods in new ways. It is also driving more extensive and sophisticated use of existing analytical methods used in conventional ways.

Automated engineering analysis and simulation tools enable engineers to more accurately model and then specify product behavior. Today, some engineers use the same model, or a close derivative of it, to drive automated verification of the design and implementation. This gives them a new and powerful tool to help address the challenges of software-intensive product development. I’m not claiming that engineering simulation is new or even that using the same simulation model to drive testing and verification is new. I am, however, claiming that these approaches have been hampered because of the isolated nature of the systems, mechanical, electrical, and software engineering disciplines. I am also asserting that the practitioner tools used within each discipline, as well as the management tools used to govern the overall product lifecycle have further complicated this problem by being largely standalone, or at best very poorly integrated. These issues create insurmountable barriers to the collaboration, information sharing, and asset reuse needed to address the bigger issues we face in complex, software-intensive product development today, much less the magnitude of those that loom in the near future.

Let’s focus back on the specific, upcoming integration of Mathcad and Integrity. How will this integration change your way of building products? For starters, it will encourage you, rather than discourage you, to connect the algorithms and parameters in your Mathcad worksheets with other related and key lifecycle assets, like the specific parameters in the product requirements you used as inputs to your equations, or the specific element in the software design model that represents the component that will implement your algorithm. You might also connect your designated outputs to the component, so that they will be right there and can easily be connected to the test harness that will be built in the near future and used to verify the component’s as-implemented behavior for your algorithms. You’ll be automatically notified of any changes in any of the connected assets, requirements, component design, source code, test design, or test harness, that may require you to make changes to the related Mathcad worksheets. With all of these important connections managed by the tool platform, you’ll be free to move on without worrying that you’ll overlook something in the future because you simply can’t keep all those details in your head and writing them down doesn’t help much either because you have to remember to review what you wrote at the appropriate time.

While this scenario does not illustrate the extent of the capabilities of the coming integration, it serves to illustrate that we will begin to use engineering analysis tools, like Mathcad, in new ways because we will be able to connect product requirements, analysis models, simulation results, design models, software, hardware, and verification assets together, creating a closed loop that enables rapid iteration. This, in turn, will enable us to validate requirements and design earlier in the lifecycle and with a higher degree of fidelity. It will also enable us to use the same validation assets to create verification protocols that ensure we are testing the as-designed and as-implemented hardware and software against the same high-fidelity models. Together, these capabilities will lead to fewer late lifecycle defects while, at the same, enabling to create more complex and innovative products.

I welcome your comment and thoughts on this topic. I plan to elaborate on it in upcoming blog entries and would like to know if you find this thread relevant to your job and your organization’s challenges.

We were startled years ago to find that every day appliances like washing machines, refrigerators, and even toasters contained microprocessors. For those of us old enough to remember when our appliances were just what they appeared to be, nothing more, nothing less, it came as a pretty rude surprise when a new generation of appliances, each containing enough embedded computing power to replace one of the flight computers on the space shuttle, started showing up at Sears. For those of you too young to remember this transition, no, I am not some old curmudgeon who hates the advances of technology in everyday life. In fact, I’m amazed at what appliance manufacturers have been able to make our everyday appliances do, by employing software. I’ve been in the industry for about 30 years now, so you’d think there wouldn’t be many surprises left for me, but it seems that the opposite is the case, more often than not. I never cease to be amazed at what creative, self-disciplined people can make using software.

Not all curmudgeons are technophobes – A scenario

OK, I guess I am a curmudgeon, but being one doesn’t mean you have to hate technology. In fact, that’s actually a pretty outdated stereotype. Not sure if you believe me? Fine. Go to your nearest Starbucks and sit there for an hour or so. In that span of time, you are nearly certain to see at least one person who is clearly well past retirement age wearing a Bluetooth headset.  This person might even be conversing with two or three others in the same age group, also wearing headsets. One or more of those headsets will probably be paired with a high-end smartphone and it wouldn’t be much of a stretch to imagine that at least one individual in this group also has a net-book or a tablet. Case closed, but since you’re already there, might as well keep watching…

As you observe said retirees, each with a microprocessor sticking out of his or her head as if it were a fashion statement, consider this: Possibly, even probably, at least one of those folks is also sporting the latest in advanced pacemaker technology implanted beneath their skin. That person is “wearing” an embedded device (gives new meaning to “embedded,” doesn’t it?) containing several microprocessors running tens of thousands of lines of code. Unlike the headsets, smartphones, and tablets, this device is not a fashion statement or a convenience. It’s essential to that individual’s survival.

But, wait… There’s more!

You may have to use a little imagination for the rest of this scenario, but I hope you’ll agree it’s not much of a test of our imaginative abilities…

The same individual may leave the store in a few minutes and get into a late-model, high-end automobile. For the sake of our scenario, we’ll say it’s a Mercedes S-class, running nearly 100 million lines of software code distributed across a real-time interconnected network of more than 70 microprocessor-based electronic control units (ECUs).*  In just a minute, some of that software, namely the code running in the car’s radar-based automated collision avoidance system*, will decide to tell the software that controls the anti-lock braking system to execute a controlled, straight-line skid – without any input whatsoever from the driver – in order to avoid a collision with the tractor-trailer rig slowing down just ahead.

Why didn’t our driver react in time? Because he was distracted by taking a call through the car’s hands-free integrated phone system that automatically connected to the cell phone in his shirt pocket right after he got into the car. True, he probably shouldn’t have taken that call in the first place, but the software-based voice synthesis component in the car announced that the call was from his cardiologist and he knew better than to let it wait. Probably for the best, since it turned out that his internet-connected pacemaker had just signaled a dangerous arrhythmia it detected in his heart, thanks to the sophisticated software embedded in it. Part of that software was adapted and reused from software originally developed for the ECG monitor device made by the same company for hospital intensive care units.

Caveat emptor

The only part of the preceding scenario that was a bit of a stretch was the part about the pacemaker connecting to the internet and possibly the reuse of code between pacemaker and ECG products. I threw those in to make the scenario more interesting and to illustrate a few points:

1. Pacemakers will, in fact, be able to signal the wearer and his or her cardiologist about dangerous heart conditions as they develop in real time in the very near future*; and
2. Medical device manufacturers will be reusing code across product lines in the near future, if they haven’t already figured out how, despite the increasingly-restrictive regulatory environment.

Why reuse the code? Because it costs a small fortune to design it, code it, test it, and maintain it, and manufacturers of safety-critical products are increasingly finding that they can’t afford to reinvent the wheel in every new product they develop.

I tried but couldn’t figure out how to work an airplane, a piece of heavy agricultural machinery, or an internet router into my scenario without loosing all credibility, but software is all over those devices too. It’s become ubiquitous. So, here’s the $64,000 question (if you don’t know what I’m referring to here or why the question is only worth $64,000, I dare you to ask one of those curmudgeons at Starbucks)…

How reliable is all of this software we depend on every day?

You might be tempted to respond with something like: ‘I have to reboot {insert name of your least favorite desktop operating system here} every stinking day! Oh, that’s just perfect! Why are product manufacturers cramming software into everything from my toaster to my car to the airplane I’m about to board? What happens if the pilots get the blue screen of death on their displays when we’re taking off?’

Thankfully, little, if any, embedded software in these devices is running on {insert name of same desktop operating system here} today. People who develop software-intensive safety-critical products are a special breed and are not given to throwing in every feature they can imagine whenever the mood strikes them while racing to get the product to market, relying on customers to do the beta testing. The software engineers among them are also not interested in developing their software to run on commercial operating systems that were developed using the same philosophy. Instead, most of these folks act and think like engineers, whether they have engineering degrees or not. The public should be thankful that this breed of person is predominant in product engineering, and more to the point of this blog entry, in software engineering. It is these people who deserve the credit for the amazing level of reliability we enjoy in our software-dependent lives today.

‘But,’ you say, ‘I hear about software-related failures in critical products and systems nearly every day!’  While ‘every day’ may be a bit of an exaggeration, this is essentially true. The important thing to remember about this observation is that you only hear about one failure every day or so all over the world. Given the pervasiveness of software in our lives along with it’s unimaginable complexity, it is nothing short of stunning that we don’t hear about 10 or even 100 catastrophic failures every day, and we have our engineers and software developers to thank for that.

Oh, by the way, some of those engineers and developers are also curmudgeons, a quality that should further endear them to us since their curmudgeonly tendencies drive them relentlessly to ask ‘Why?,’ and ‘What if?’ and to make irritating statements like ‘Oh really? You’re wrong and I can prove it.’ If you work or live with one of these people, I offer my sincerest condolences. I also encourage you to talk to my wife for some pointers since she’s developed some very effective coping skills over the past 26 years. While this behavior can lead to products that are late to market and cost more than we’d like, we all know of examples of products that did not benefit from this kind of thinking and can probably all agree that, given the choice, we’d choose the more expensive and late to market product over the other one when our lives will depend on it.

That’s all well and good, but it’s not enough

Despite our best efforts, software development is a monstrously complex undertaking and software-driven complexity doesn’t appear to be abating at all. Embedded software developers, with their real-time operating system kernels, specialized development environments, rigorous development processes, and increasingly rigorous quality standards, are still prone to make errors which sometimes slip into the final product. And while we may all agree that we’d wait longer and pay more for a safety-critical product in a hypothetical scenario, the real world of the 21st century is one in which product manufacturers must:

1. Understand market needs better and faster;
2. Create ever more innovative products to meet those needs;
3. Bring products to market faster;
4. Design, manufacture, and service products at lower cost;
5. Ensure products comply with a growing body of regulatory requirements and industry standards; and
6. Deliver increasing value to shareholders (a requirement that is not always in perfect alignment with the previous ones).

Collectively, these requirements are driving manufacturers to dramatically increase their use of software, both embedded in the product and in the product support infrastructure, to enable rapid innovation and, at the same time, help meet the remaining requirements which can be summed up as better, faster, cheaper, and more reliable. It’s a daunting task to say the least.

So, there it is:

The challenge of the 21st century for product manufacturers:

To drive innovative products to the marketplace better, faster, and cheaper through increasing use of software while ensuring reliability in the face of dramatically increasing product complexity that is the result of greater reliance on software. 

Of all the challenges associated with the increasing role of software in products,  safety and reliability will be the most public aspects of them for the rest of the century and will thus be the primary driver of changes in the way we engineer complex, software-intensive systems and products.

Is this an intractable problem?

Since the challenges are interdependent, they cannot be addressed independently. Instead, we will have to approach developing solutions to these challenges in a holistic manner. That’s where an engineering discipline called systems engineering comes into play. Systems engineering actually began as a formally recognized engineering practice area decades ago, in the days when we were regularly solving intractable problems, like putting a man or two on the moon, bringing the crew back to earth alive, and doing it several times over to prove we weren’t just lucky the first time.

Those challenges were far too large and intractable to approach using conventional engineering methods.  They required a holistic approach that could divide the problem into smaller chunks each of which could be engineered separately while not losing sight of the system as a whole. That’s what systems engineering is all about.  The practice of systems engineering has matured over the years to meet even greater systems challenges. However, some aspects of it have not matured at the same rate as others, leaving engineers with some gaps in the methods and tools they require to do the job right.  And, that’s where I’ll quit on this already too long posting.  Look for future posts where I and others will write about these gaps and the need to advance the practice of systems engineering to a new level of maturity in order to meet the seemingly intractable problems we will face this century.

What do you think? Will software safety and reliability be the driving factors in product engineering in the 21st century?

In my opinion, ALM is not a fancy shiny tool as some people may suggest – it’s a way of life in the software development world. The challenges facing software development today include: managing software development assets and the relationships between them; full lifecycle process automation and enforcement; re-usability of development assets; having a single source of truth for development; configuration and change management across all activities and assets; instant visibility into release readiness, plus much more. So you need ALM to help you manage your software development and project management — it keeps all teams informed of what’s happening in the software engineering process.

An enterprise ALM platform will help coordinate and manage all activities and artifacts associated with developing software as part of an embedded product or as a standalone application including: Requirements Management, Modeling and System Design, Software Configuration Management, Test Management, Defect Management and Release Management.

Then there is traceability which is not just for requirements. Traceability across disciplines is where the true value of a software development lifecycle solution lies. Traceability is also critical when developing variants and software product lines. In a complex software or system development environment with extensive use of reuse and variants, measuring impact across projects, components, subsystems and libraries surfaces the true cost of change to the organization. Therefore, traceability across reused assets is also essential in quality assurance.

Another aspect to consider is making sure that your end product is scalable and has multi-platform capability to support large scale software reuse initiatives, workflow-based collaboration and rich mining of application activity data to deliver higher team productivity, visibility and compliance for software engineering and IT organizations.

Here are some resources you can check out & let me know what you think?

Aberdeen Group: Embedded Software – The Future of Innovation in Tomorrow’s Products

Ovum Technology Research Report:  Software Lifecycle Management 2011/2012

Blog on “Flattened Requirements Management”

Carmakers are not new to technology, but statistics show a trend these companies cannot ignore: a record number of consumers site in-car systems and technology as a top consideration for their purchase. In fact, during a PCMag interview at CES, Ford CTO Paul Mascarenas said, “We have data that shows more than 50 percent of people buying new cars say that Sync was one of their key priorities, along with fuel economy and safety.”

The last time I checked, a car was for transporting passengers from point A to point B. What would the pragmatic Henry Ford say about this phenomenon?

I think relaying a recent story from my life will underscore how fundamental this shift is. I have a very technology-savvy friend who loves all practical, elegant, high performance technology products. One of his interests is automobiles; he has purchased somewhere between 15 and 20 new vehicles in his 24-year driving history. Lotus, Audi, Ducati, Acura, Honda, and VW are some of the brands he has owned. Another key statistic: not one of his many vehicles was American-made.

Ok, now that I have laid the groundwork, on to the story. I called him a few months ago and shortly into the call, I inquired where he was. His reply: “I am driving in my new Ford Explorer in Orange County, CA.” When I had regained my senses, many questions flashed through my mind. What happened to him? Did he win this vehicle in some raffle? Had someone subjected him to some mind-altering brain washing exercise? When I asked him how he could have possibly purchased a Ford, his reply was, “In my opinion, Ford’s technology is years ahead of all others in its class, including BMW, Acura, Audi. Ford Sync is very, very impressive!”

Technology not only swayed him to purchase the vehicle, it actually overcame a very significant negative bias. The software won him over. In that same interview with PCMag, Mascarenas said about the role of software in vehicle innovation, “So much of it becomes software-based. Look at Auto-Park Assist, the technology that will automatically park your car for you. Delivering Auto-Park Assist is all software, it is all about the algorithms. Everything else is already in the car—the cameras, the radar, the power steering, the power train. You just need the software to make it work.”

The role of software is huge in modern vehicles, and no more true than in the world of hybrid and electric vehicles. Fisker was there at CES with its incredibly cool Karma. This car oozes with software. The crystalline drive selector, 10.3 inch center dashboard touch screen, virtual instrumentation panel from Visteon, TomTom software navigation integrated into the infotainment system, and drive mode selection from Sport to Stealth modes are all very software-intensive systems that make the car what it is.

Technology and software are key drivers in automotive and there is no evidence that this trend will end anytime soon. At the recent Detroit Auto Show (NAIAS), the top automotive companies were joined this year by several technology companies such as Tata Technologies and Schaeffler Technologies as further evidence of this trend.

He predicted that in order for organizations to succeed in this flattened world, they need to learn to work closer and more collaboratively with their suppliers. He used Walmart’s inventory and supplier management system as an example. The key to Walmart’s success is the exchange of information between the retail stores, Walmart, and its suppliers. Walmart is able to monitor how many of a product is sold at each location, and instantly instruct suppliers to create more product to replace that sold, even when those suppliers are in China, India or the Mid-Western US. This interchange, in addition to optimizing transportation and storage, has enabled Walmart to cut costs to the point where it’s almost impossible for competitors to compete with them on price.

Product development today has evolved into a technology supply chain and functions similarly. Original Equipment Manufacturers (OEMs) manage a complex network of suppliers, sometimes several layers deep, in order to develop their products. A typical PC purchased at an electronics store may be assembled in a factory in Thailand from hardware components provided by suppliers in China, Taiwan, India, and Japan. An automobile today is an assembly of hundreds of pieces or systems, developed by multiple suppliers. Ford may source its brake system for a new model from one supplier, who in turn may source the anti-lock brake electronic control unit (ECU) from another company, and the brake disk from yet another.

These product development organizations face a challenge that Walmart doesn’t, however. Getting a product to a shelf in a Walmart store requires a relatively simple flow of information. The store indicates the sale, Walmart passes that information to the supplier, the supplier creates the new product, and then the shipping information is managed as the product is carried to the store or stores. When a company like Ford sources a brake assembly from a supplier, the development of the assembly requires regular collaboration across corporate boundaries. Design information is passed back and forth to define the exact needs of that assembly, which are changing as the design for the automobile evolves. If the specification for the automobile’s chassis changes, the automobile’s new weight may need to be sent to the brake assembly supplier and the suppliers developing the power train so they can input the information into their models for testing.

This is further complicated by the increasing amount of software included in products across the spectrum. Software requirements for a Blackberry phone can be in the thousands, and each telecommunication company and market across the world has  different demands. These requirements change rapidly, and so there is a constant flow of requirement and design information between the product development organization, its customers, and its suppliers.

Friedman also predicted the solution. He wrote “the more these supply-chains proliferate, the more they force the adoption of common standards between companies.” The automobile industry was the first to recognize this need, and a collection of organizations put together the Requirement Interchange Format (RIF) standard, now called ReqIF, with the intention of

• improving the collaboration between partner companies through enabling organizations to apply requirements engineering methods across company boundaries
• providing organizations with the ability to use the requirements authoring tool of their choice, and eliminate the need for suppliers to implement multiple requirements management tools to collaborate with all of their customers
• enabling better collaboration within a company, as information can be exchanged even if different disciplines use different tools to author requirements

I’m going to add to Thomas Friedman’s predictions with some of my own. Everything from household appliances to medical devices are becoming smarter, more networked, and more sophisticated, and the components that make them up are becoming more specialized. As products become more complex, supply chains are going to continue to lengthen and broaden, and the inefficiencies in how organizations collaborate today, usually through email and monthly or quarterly meetings, will compound. The successful hardware, electronics and software providers of the future are going to be those who can collaborate and partner with multiple suppliers and customers in real-time, to produce working systems, and systems of systems, and they’re going to need to be able to demonstrate that these products are compliant to process standards and safety regulations. In this environment, supporting a standard such as ReqIF will become more than a competitive advantage, it will become a necessity.

Like many organizations in its industry, rapid growth through acquisitions over the last 10 years had created a collection of product development groups in silos, each with their own methodology and supporting tools. Getting portfolio level information in this environment was time consuming and sometimes even seemingly simple tasks, like tracking down which features had been implemented in which products, were difficult. Their ability to innovate and respond to change and opportunities in the market was becoming bogged down with inefficiencies and redundancies. Product development wasn’t able to respond to customer and internal feature requests quickly or efficiently, and the organization’s visibility into product releases was very limited.

One major source of pain was that each product and product line had their own process for receiving requirement and feature requests. This resulted in inconsistent features across product lines and wasteful ‘re-inventing the wheel’ implementations of similar features. It also made tracking which features were available in which products extremely time consuming, even after products had gone to market. To address this, the organization created a single ‘backlog’ system to collect and manage requirements and feature requests, and they established a release planning process where the requests were reviewed, estimated, prioritized and assigned to product backlogs.

Each development group replaced their systems with a well-known Agile development management system and trained their teams in agile development methods. The product backlogs are managed in the Agile point solution using fairly standard Scrum techniques with Sprints, Sprint Planning sessions.

Adopting this Agile-like process improved requirement traceability and the organization is already seeing results in product quality. Requirements change management is much more effective, and when requirements change and new requirements and requests are received, the information can be immediately communicated to the teams through their backlogs. It is much easier to track the progress of features though out the development process.

However, using independent Agile point solutions revealed some issues they were having applying Software Product Lines. While agile improved communication within teams, having multiple independent product backlogs didn’t improve the collaboration required between products and product lines, and the faster development iterations made this more visible. Maintaining a common architecture of features across lines was a cumbersome process because there was no easy means for teams to provide feedback on the architecture. Variants and products with similar requirements sometimes re-invented the wheel, creating new assets for features that had already been developed and tested by another team. When defects were revealed, it was difficult to determine whether this defect also applied to other variants. Issues found in one variant were not always communicated to other variants.

To be clear, the company knew that moving to Agile wouldn’t solve some of their challenges in adopting SPL, and planned a second step. The separate Agile systems used to manage development activities and assets will be replaced with a single repository. Development teams will work from the same assets and be able to use configuration management concepts, such as branching and version control, to the requirements, user stories, test plans and code. For example, a test plan may be created for one product line, and then other lines will either share that test plan or create a branch if they need to diverge from the core architecture. Through  automated traceability and trace propagation functionality, the teams will be able to view and leverage work being done in parallel on other variants while automatically communicating their own changes.

So, through the use of Agile and configuration management concepts, this company is managing to overcome some of the hurdles  product development organizations face when combining Agile and SPL, and therefore leverage the benefits of both approaches. I’ll be looking at another very different case in the next installment. I’d like to hear your experiences, so please feel free to comment below.

Complex Systems Theory is, not surprisingly, difficult to describe in a nutshell. A complex system is a system composed of actors that interact with and influence each other in many different ways. It is essentially a network with nearly infinite relationships between the actors. Natural ecosystems are good examples, where millions of animals, plants, bacteria and fungus interact and affect each other in uncountable ways.

Complexity Science studies how this variety of actors and interactions can result in “spontaneous self-organization.” The system organizes itself, adapts, and evolves without anyone directing or planning the organization. The adaptation is a result of actors constantly adapting to each other. The international stock markets dropping in reaction to a news report is an example. No one person held a meeting of all the world’s stock brokers and said “SELL SELL SELL!” Some read the news and adjusted their portfolios. This lead to others adjusting their portfolios and so on. Another example from nature is a community of ants changing to a new food source. The queen ant didn’t send out royal directives. One ant found a new food source and interacted with some other ants and then your picnic basket was overrun.

The study of complex systems has also been applied to business, in particular to management and the engineering and manufacturing of products, as a way to encourage innovative thinking and rapid responses to change. Traditional management relies on the idea that the business environment is predictable, and so business strategy and product development can be planned months ahead and instructions can be passed down the hierarchy. But anyone trying to manage a requirements document in a software development project will tell you a different story. The modern business world is unpredictable, fast moving, and incredibly complex. Complexity science tells us that if given the right environment, the people in an organization and their relationships can spontaneously organize and adapt to change much faster and more successfully than a hierarchically controlled system. Thus Agile works because it is empirical and adaptive, not a defined process. The team experiments, learns and validates continually rather than adhering to a restrictive and sometimes inappropriate process.

Re-reading Schwaber’s book reminded me that with the complexity of software development, success requires the self-organization of the team. I often get lost in the ‘process’ of scrum, the sprints and scrum meetings and backlogs and reviews, forgetting that scrum is almost an anti-process. The ‘process’ of scrum is simply creating as little process to dictate behavior as possible, and instead ensuring the optimum environment for the team to self-organize. Scrum is about removing impediments and distractions and enhancing communication and collaboration. The sprints and reviews are not intended to tell the ants how to get to the picnic basket. They’re there to enable the the team to find a faster and better way to the picnic basket, even if someone keeps moving it.

Functional safety is not a new concept, so why is it such an important topic in the automotive world these days?  The short answer is the complexity of the modern automobile coupled with recent high profile systematic failures have demanded a more thorough, more detailed, and more domain specific functional safety standard.
That being said, it is helpful to understand the answer in more detail by looking at:

• A brief history of functional safety

• What functional safety is in simple terms, with pictures

• The role of software in embedded system complexity and functional safety

A brief history of functional safety
The notion of functional safety was introduced in the 1980’s as a means to evaluate complex devices as part of the overall safety function. In 1998 the IEC published a document, IEC 61508, entitled: “Functional safety of electrical/electronic/programmable electronic safety-related systems.” IEC 61508 was originally developed for industrial machinery and chemical plants and remains the relevant standard for many industries.  In recent years, however, many industries have looked to develop domain specific standards that are better suited to their application and can handle the immense rise in system complexity driven by many factors including the exponential growth of software. Specifically, the automotive industry is set to launch the new ISO 26262 standard, which is an adaptation of IEC 61508 for road vehicles. ISO 26262 takes a lifecycle approach and focuses significantly on development processes as a means to proactively design safer automobiles.

What is functional safety?
According to IEC 61508, functional safety is freedom from unacceptable risk of physical injury or of damage to the health of people, either directly, or indirectly as a result of damage to property or to the environment. Functional safety is part of the overall safety that depends on a system or equipment operating correctly in response to its inputs. In more simple terms, it provides the assurance that the safety-related systems will reduce the risk of injury to a tolerable level. Figure 1 does a good job of illustrating this. ISO 26262 focuses on the Electronics and Software Systems more specifically.

Figure 1: Functional Safety

Furthermore, it is important to note that functional safety relies on active systems, not passive. For example a sensor actuated fire sprinkler system is a functional safety system, whereas, spray-on fire retardant is passive and therefore not a functional safety system.

The Role of Software
Software is fundamentally changing the way products are engineered, manufactured, serviced, and used. Software is growing at an incredible rate in almost every manufacturing industry, but automotive is arguably in the lead pack. Software brings with it many significant benefits, such as late design flexibility, an almost limitless capacity for innovation, reduced manufacturing costs, improved product variability and product line support, and significantly improved product serviceability. Unfortunately, as with most things in life, these benefits do not come for free, or even cheaply — software drives incredible product complexity and high velocity change that must be managed.

Software within electronic systems is also playing a larger and larger role in functional safety and must be a major design consideration from the beginning. Hardware-centric systems engineering practices are a thing of the past for market leading organizations. ISO 26262 addresses this with a balanced triple V model approach, such that system, software and hardware are all accounted for within the standard.

Conclusion and Recommendations
In this short entry, I have barely scratched the surface of this important topic and therefore will be addressing several other areas in upcoming installments in this series.

Here are a few recommendations I have gathered from current customers in this industry:

• Take a close look at ISO 26262 and begin to address this standard in your development processes sooner than later

• Look at your tool chain and consider consolidation as a means to better support critical requirements such as traceability and also as a way to streamline compliance

• Consider the growth of software in your products and how you might proactively address software driven challenges in your lifecycle management practices

Let me know if you found this post useful and please come back for future installments in this series. I would also invite you to a follow me on twitter @mfklassen.

Can aerospace and defense companies benefit from implementing software product line techniques and tools? Where’s the SPL ROI in the A&D industry, if there is one? In this blog series, we’ll examine the SPL practice and consider its potential value and risks in this specialized world of complex, high-consequence products and systems.

Before we start into the topic, it might help to begin with a definition:

“Software product lines (SPL) refers to engineering techniques for creating a portfolio of similar software systems from a shared set of software assets using a common means of production.”  –softwareproductlines.com