What is concurrent engineering?
Concurrent engineering is when activities are paralleled that could be sequenced. Concurrent engineering can help us deliver the product earlier since we have compressed the schedule by overlapping the various development activities. There are certain risks associated with this way of working. To be successful and not incur massive rework, it is necessary to keep the entire team in step, essentially plenty of communicating and synchronizing the design direction. This requires constant attention to the design interactions and dependencies, specifically, the links between the design areas. For example, if we are developing a new vehicle, we will need to coordinate the structural, hydraulic and pneumatic, as well as the electrical design. Continuous reviews and a well-defined configuration and change management process can help to keep the team in step.
Concurrent Engineering Failures
There can be a down side to concurrent engineering. Done poorly, there will be an abundance of rework. We “detect” problems when the physical parts come together in a bundle of parts that cannot be assembled. We do not help our situation any when we have a variety tools for each of these areas. For example, consider a company that uses Pro E for some of the CAD work, and Catia for other design elements. Sharing of the various digital models that will eventually comprise the system is necessary. The ability to view shared digital mock ups (DMU) ensures we are constantly aware of the design direction. We know the other system elements design state. This is a key component to successful design. Additionally, the construction of models in one tool will make the assembling of those modules into the final product will in advance of the construction of the system via prototype parts. This is one of the key benefits of building DMU of the system to provide a virtual construct of the product. A design that fits together in CAD may be a design that will work in reality. With this disjointed or inconsistent use of tools, building a virtual representation of the product will not be possible or will require human manipulation which will consume time and adds an opportunity for a mistake to creep into the design.
Concurrent Engineering Summary
Concurrent engineering is not as easy as it may sound. To be sure, if you proceed with a measure of diligence, sharing of the design data and good communication, we can be successful. If we are unwilling to take this approach, expect concurrent engineering to produce rework, and waste – and only occasionally successful.
2 Comments
Ravikiran Saralaya
Very informative article, with thoughtful initial planning and due consideration to compatible design/development environments, upfront communication and data sharing it is possible to reap the benefits of concurrent engineering.
How can the benefits of concurrent engineering be extended to final integration or system testing phase, especially in a software development scenario? I have been through many products wherein the components were ready to integrate in fairly less time. We could not continue the same pace into the integration phase and it always looks like there is a strong bottom up dependency for integration and testing. Early Simulation/ HIL testing helps to certain extent but doesn’t yield expected time reduction.
admin
Thank you Ravaikiran,
Simulation via HIL or SIL will only take us so far, and that distance has to do with fidelity of the models to the end system. However, I think the key to quick and successful systems integration test has two components.
First we need to make sure the test subject is ready to go when the material arrives. This seems so obvious (because it is obvious), but I have seen many instances when the software and hardware arrives and a suitable (test worthy) vehicle is not available for the integration work. It is likely you have witnessed this same scenario – where the test vehicle is either not there or abomination and does not meet the needs (for example – errant configuration) when it comes to testing.
Secondly, we should not wait until the end to consider the systems integration. We should take a play from the agile playbook and build incremental iterations of the system on the way to the final product incarnation. In modern vehicles the functionality is distributed over a number of components, both hardware and software, connected by communications networks. This requires a level of concurrency as well as we build cohesive system functionality among the constituent parts in a controlled manner that distributed functions mandate. For example, a speedometer will only work if the message is broadcast – both items must be in place to test. We can do this incrementally based upon some priority (for example: most difficult, most risky, or most valuable). We then orchestrate the growth of our entire system. Our configuration management process and plans will define the system growth via baselines that our components and software are to achieve.
In this way, our system development is inextricably linked to our integration and verification activities on the vehicle. Our system is constantly critiqued through the iterations and can better keep up with the development work since the package is clearly defined in our incremental baselines. The scope of the test work can be focused on the new package contents and testing of prior iteration fault reports reducing time to test as well.
Check out the link below, perhaps it will help.
https://valuetransform.com/?s=TIEMPO