A lot has been written and discussed regarding the effects of the COVID pandemic on how we work. Changing from working in the office to working from home is likely the most discussed topic. Here is a great recent blog on this very subject by Barclay R. Brown. Judging by the number of reactions to the blog, this issue is on many people’s minds. My own experience at Aras is that a pivot away from a central office was not a problem at all if the company already had an infrastructure in place and a well-developed culture of working from home. Here is a recent study from MIT Technology Review that looks at why some companies were so successful with that shift thanks to solid business reasoning that actually had nothing to do with the pandemic. Of course, this shift is more than just to screens and laptops at home with a robust internet connection to the company’s servers (plus a big enough closet that can be converted to a home office!). The shift to working from home also includes the need to collaborate remotely. For advanced product manufacturers this means that there must be a robust infrastructure that allows access to highly complex and highly distributed product design data captured in the form of Model Based Designs (MBD). And that has significant consequences.
Engineering V Model
When looking at MBD through the lens of the engineering V model it is obvious that the MBD concept includes all design representations at all abstraction levels across all domain and expertise silos. MBD spans parameterized and configurable requirements, system models (MBSE), simulation data (SPDM), variability (features, options, rules, PLE), detailed designs (mechanical, electronic, software), and so on. This, by the way, is in direct contrast to a narrow interpretation of MBD as applicable only to 3D CAD representations of mechanical designs. As I mentioned, MBD data tends to be very complex and highly distributed and therefore the idea of keeping it dispersed across multiple home clients is not an effective way for engineers to collaborate. This does not mean that silos as such are bad. Domain and expertise silos are important and likely here to stay because they shield people outside of the silos from the details that are irrelevant to them. But that works only if the details that are relevant outside of the silos can be exposed and communicated. That is the role of a modern PLM platform—building multiple digital threads that allow users to see the forest from the trees, regardless of the silos, AND allows them to navigate to the tree (in a silo!). What’s needed, when it’s needed digital threads that address a task at hand.
This has an interesting implication for what is contained in a digital thread. How much of that is explicitly defined in a PLM platform, and how multiple threads that emerge in different parts of the business will, in time, connect with each other. Digital thread that is data model or tool specific will quickly become stale because the type of data that it needs to trace keeps changing as the technology used in complex products evolves (e.g.: insertion of AI or adaptation of a generative design process). It needs to allow navigation to such technology or data model details, through a common and tool-agnostic system abstraction that does not depend on the specifics of an implementation domains. That is a big part of Aras’ Systems Thinking message. But that is a material for a different blog.
While the industry push toward a variety of digital threads managed via PLM platforms has been taking place for quite a while, the massive and sudden move away from the office due to the pandemic changed the key aspect of this push. In the 2019 there was occasional talk of the potential value of a cloud-based PLM platform. Now, every conversation about a PLM platform is based on the assumption that it is, in fact, cloud-based. A clear shift in the way we’re thinking about the infrastructure that we need to support design of complex products.
However, there is one aspect of the engineering V model that a cloud-based PLM is not likely to resolve as long as the pandemic is real. It is the scope of activities that occur on the right-hand of the V model: physical integration, first manufacturing build, and debugging of the pre-production runs. This is because these activities are based on the physical presence of the engineers—and that is not home offices. While a cloud-based PLM provides access to the digital thread that runs through the relevant MBD data, it does not replace the need for a physical presence of the engineer on-site. I don’t have an answer for this although virtual testing has a role here. Perhaps some sort of a combination of augmented reality with IoT and AI capable of spotting discrepancies between MBD and the hardware will minimize reliance on a physical human presence. Time will tell—sounds like an opportunity for a startup of some sort. And once this level of remote functionality is reached, perhaps then the need for an on-site engineer will be eliminated just like the reliance on working from a central office. And all that due to COVID.
What do you think?