Building sustainability into product development with requirements-based engineering

Posted on 15 Sep 2022 by The Manufacturer

Hedley Apperly, VP and GM Systems and Software Engineering at PTC, examines why requirements-based engineering is the hidden weapon in achieving sustainability in product development.

The sustainable performance of a product is growing in importance and is now viewed as critical as traditional design criteria, such as size, weight, cost, and performance.

It is no longer seen as a nice add on, in fact it is fundamental and needs to be built in from the outset. The challenge is to close the loop so that we ensure all requirements are built into the process upfront and carried through the design and engineering process and verified by valid tests throughout the engineering lifecycle.

In the present landscape, we use a mixture of CAD, PLM and developing software to try to define requirements and this approach makes it increasingly difficult to collaborate effectively. This will all change with Codebeamer, a product we recently added to our portfolio when PTC acquired Intland.

This web-deployed product focuses on requirements engineering, risk management, and test management linked and traced together. It is powerful in areas such as agile, facilitating contemporary approaches to design and integration with technologies like GitHub, and Jenkins for CI/CD pipelines. It also delivers numerous out of the box templates that offer processes ready for critical aerospace and defence (DO-178/DO-254), automotive (ISO 226262) and other industry standards.

Facilitating collaboration and closing the loop

Rather than just relying on ad hoc documentation and then going straight into the design, PTC can now provide a complete upfront ‘requirements engineering’ environment that leverages the power of agile.

People can work together, and you can have a range of stakeholders. People with different viewpoints can document those requirements together so that when you move into design, CAD, or the software environment, which you are recording in ALM or PLM, you can reference back to those requirements until you are satisfied.

The critical capability, not just for software but also for the whole product, is the environment for defining the requirements of the product. Historically, or in other settings, this is conducted by email, word documents or spreadsheets. Using a database-centric, multiuser environment, you can define the requirements for all the stakeholders, track them, and make sure you have not missed any.

It is not just the sizes and colours of the parts that can be tracked for example, but also any sustainability or ecological requirements. This means that you can have stakeholders for the product design, security, renewability, ecological and environmental concerns at the front end, all contributing to the result.

Then at the back end, we create tests for the product that ensure these requirements are satisfied – in essence, we’re creating a virtuous loop to ensure that what was implemented and delivered meets those original stakeholders’ requirements.

Moving to requirements-based testing

Part of closing this loop is validating that the end product meets the requirements and that it is conducted through testing. Traditionally, you would adopt a back-end testing approach, but the trouble with that is you cannot test in quality; this must be designed.

Creating those tests right at the beginning and having them linked up and not having a separate discipline of Quality Assurance that is isolated from the designers, means you are proving the requirements. It goes both ways; you want to make sure that you are not only testing everything you need, but also not delivering things you do not need.

It is both building the right system and building it right. Reviewing system requirements in the planning phase of a test effort reduces rework, errors, and defects.

The connection between requirements, design and testing is essential. When defining a need for a product, such as a car’s stopping distance, several parameters combine to enable this. The best time to create the test plans for the whole product is while you are defining those requirements because they lead straight into one another.

When you do this in Codebeamer, you can create the tests as plans right up front when you are defining requirements, and they are linked and traced together, so you know which test is testing which requirement. First, you validate the test to check that they are valid and meet testing requirements, then later, you verify the product and make sure it matches the test. So therefore, proving the product does what the stakeholders want you to do.

Integrating with Windchill

PTC already has a highly successful PLM solution in Windchill and Codebeamer’s ALM and requirements-based engineering approach complements this offering. In addition, we are currently working on extending Codebeamer with Open Services for Lifecycle Collaboration (OSLC) which Windchill already has, so that in the near future it can connect to the PTC Digital Thread.

That means you will be able to link the requirements to the parts that satisfy the requirements. You will also be able to look at a part within the Windchill PLM and, without leaving it, view the requirements it is satisfying. This could be the type of material, where it is being used, sourcing, right through to what size it needs to be, and what performance you require. There is direct linking within a shared database, even though Windchill and Codebeamer are separate tools.

Take a car for example. It will have high level requirements such as the total cost, which is a summation of all the subpart costs. The same is true for weight because that impacts the range and acceleration of the car, and the carbon footprint.

Codebeamer is agnostic of the type of requirements. Customers are already using this ability for fuel consumption or power consumption on the car and the range. We have already worked with customers like BMW, Mercedes and VW and some of our involvements are more in the product, and some are more about the environment outside the product.

However, that can now be expanded to control the carbon footprint of a product by making it a requirement upfront. This will enable you to measure the addition to the footprint from all the supplied parts that go together to build the car. Then, using requirements-based testing, there will be a test at the end that ensures the sum of those parts meets the requirements built into the original design.

As we move towards a net-zero future, the capability to verify a product’s carbon footprint will become ever more essential and allow manufacturers to satisfy the sustainability demands of consumers.

Read more of our Sustainability articles here