Commercial or In-House Tools for Electrical/Electronic Systems Development?
May 06, 2021
Story
Many products rely on sophisticated electrical/electronic (E/E) systems to deliver their end user functionality.
As E/E content grows, good choice of software tools supporting E/E systems development has become a critical decision. Yet the E/E domain, which spans disciplines as diverse as embedded software coding, data network verification, and power analysis, is served by a mixture of commercial-off-the-shelf (COTS) and one-off applications developed in-house. Several factors impact this “make” versus “buy” decision. This article covers three key areas that managers need to consider when analyzing their engineering tool landscape: flexibility to address the company’s needs, enterprise integration across engineering and process environments, and security and intellectual property (IP) protection. Each of these areas will help management weigh the relative benefits of COTS versus in house tools, and determine the most effective decision for their organization.
To optimize today’s E/E systems development landscape, these three technical aspects are critical when assessing whether to make or buy software tooling:
Flexibility
First is flexibility. COTS tools need to be highly flexible and adaptable to the specific needs of each company, team, and engineer. This is because of the lack of widely adopted standards for certain aspects of the E/E domain and because of the existence of many different design and process flows. This is particularly true for suppliers who must support multiple OEM customers, each of whom may use different data formats. This challenge is often cited as a reason for pursuing in-house development because roadmap control is easier. Other E/E domain examples where flexibility is required include:
- Workflow variation
- User management
- Design and manufacturing process variation
- Data import, export, and reporting
- Simulation, checking, and verification requirements
- Object naming
- Graphical styling
COTS tools must therefore support a high level of configurability. If out-of-the-box behavior can be adjusted without resorting to external customization, ongoing maintenance costs are minimized and software licenses can be efficiently used for different projects. If the desired behavior cannot be achieved through built-in configurability, external customization (extensibility) will be needed. In this situation it is critical that the tools provide a futureproof application programming interface (API). In this way, external customizations can be maintained at minimum or zero cost.
Examples of specialized behavior accomplished using configurability and extensibility are shown in figures one and two. Figure one shows the application of customized rule checks to a schematic design. Figure two shows two graphical representations of a wire harness automatically generated from the same dataset.
Figure 1: Use of customized design rule checks.
Figure 2: Alternative graphical representations of the same harness design dataset.
Enterprise Integration and the Comprehensive Digital Twin
The next critical technical capability is enterprise integration, or the ability to link seamlessly with adjacent engineering and process environments. For E/E system development, the list of potential adjacent domains is remarkably long. It is therefore vital that COTS tools are designed to operate as part of an ‘open ecosystem.’ In addition to the more obvious adjacent engineering applications such as PLM and ALM solutions, common integration needs include user authentication, workflow and release management, requirements engineering, functional design, 3D mechanical CAD, product planning, software integration and testing, service documentation and diagnostics, manufacturing execution systems, and factory equipment. Supporting such extensive enterprise integrations allows the E/E systems domain to contribute to a comprehensive digital twin that models every aspect of the product itself, manufacturing processes, and after sales support.
The number of potential integration patterns is almost infinite. And while some structures and standards exist (examples: UML, SysML, FMI) COTS tools must be architected to integrate with unknown third-party environments as a core principle. The nature of integration architectures varies somewhat. Some adjacent environments are very pervasive, such as the leading 3D mechanical CAD platforms, so it makes sense for COTS vendors to offer standard integration products. But because of the vast array of enterprise integration patterns such tools must also provide a large number of integration hooks, such as the ability to publish and consume web services. Just as with software extensions, it is important to consider which integration technologies to leverage, to minimize, or eliminate ongoing maintenance costs. Fortunately, newer technologies such as RESTful services and low -ode application development platforms are making it easier to create seamless mashups. Thus, companies favoring in house tool development must continually familiarize themselves with such technology evolution.
IP and Security
Third, protection of corporate know-how is frequently cited as a reason to reject COTS tools in favor of in-house development. A simple example of such IP could be ‘we never allow more than six wires in an electrical splice because we have learned that more than six is unreliable’. The solution is for COTS tools to include a mechanism by which IP can be captured privately and, just as important, systematically applied. Technically, this can be done by providing very rich configurability and extensibility capabilities. In this way, COTS tool behavior can be adapted to incorporate all manner of unique design and process IP, and to hide the IP from the outside world. Examples are shown in figures three, four, and five. Figure three shows part of a bespoke rule deck controlling wiring synthesis, in turn built from rule primitives like those shown in figure four. This approach allows companies to gain the benefits of economy, innovation, and business focus delivered by COTS solutions.
Figure 3: Snippet of a wiring synthesis rule deck.
Figure 4: Examples of rule primitives.
Figure five shows the dialog used to define bespoke manufacturing process patterns against which wire harness manufacturing process trees can be generated. Similar technology can be used for detailed harness manufacturing cost calculation, which is an especially commercially sensitive subject.
However, just the provision of infrastructure supporting configurability and extensibility of COTS software is not sufficient. To support true proprietary protection, it must be possible for the customer, or their trusted third-party contractor, to implement their own software configuration and extensions (i.e. to be independent of the COTS tool vendor). To support this, appropriate documentation and training must be readily available, and common programing languages such as Java supported.
Figure 5: Dialog used to define wire harness manufacturing process patterns.
Of course, IP protection does not end with tool configurability and extensibility. Another aspect is the transfer of data between organizations, for example between OEM and supplier. It may be necessary to transfer proprietary information without exposing the proprietary content itself. For example, electrical engineers may need to transfer an electrical design containing proprietary simulation models that can be executed. The solution to situations like this is to encrypt the models so that only authorized staff possessing decryption keys can view their actual workings, but the models can be executed by other staff.
Engineering software must also be able to guard against malicious activity, such as the deliberate theft of IP. All tools and the environment within which they operate, whether COTS or in-house, should employ counter measures to detect and repair vulnerabilities. In this case, COTS vendors can provide superior capabilities because of their clear core competence in software engineering, including awareness of the latest security technologies such as secure communications between databases.
Finally, it is important to manage user access within an organization. Staff may be assigned to one project but restricted from another. For example, staff within an aerospace company may be assigned to either military or civilian projects, with access to the military projects tightly controlled. Modern COTS software solutions feature configurable privileges to allow only certain projects to be accessed, or indeed visible, by individual users or groups of users.
COTS software can deliver appropriate IP protection in each of these areas via a combination of configurability, extensibility, security technologies, and functionality.
Trends Indicate COTS Dominance
Many industries have faced the ‘make or buy’ decision. In the case of engineering software, the trend is clear: COTS suppliers have continually grown market share, diminishing in-house software and non-specialized tools almost to the point of extinction. Typically, a group of dominant COTS suppliers emerges, often complemented by an ecosystem of adjacent vendors. These large suppliers are able to achieve economies of scale as their revenues are sufficient to support significant development teams while remaining profitable. This means the COTS platforms become very powerful technically, making in-house development economically unattractive. At this point, factors such as innovation and strategic business focus also come into play, further diminishing the value of in-house development.
Other domains have already undergone the transition from in-house to COTS software solutions, including:
- 3D mechanical CAD: Siemens Digital Industries Software, Dassault Systèmes, and PTC have become major COTS suppliers.
- IC design: Mentor Graphics (now part of Siemens), Cadence, and Synopsys have become major COTS suppliers.
- Enterprise resource planning: SAP, Microsoft, and Oracle have become major COTS suppliers.
In all three cases, in-house development can now only be justified for the most esoteric situations.
This pattern is clearly playing out in the E/E systems domain. In-house applications are being replaced by COTS tools and the virtuous circle of economies of scale leading to ever more effective COTS products is well underway. For example, all ten of the world’s top ten automotive OEMs now have COTS tools at the core of their electrical design environments. Tasks such as schematic capture are now very rarely best supported by in-house software, and subjects such as configuration control, cost calculation, and harness manufacturing engineering are rapidly moving in that direction.
A recent example in the E/E domain is data communications network design. This has often been accomplished using bespoke spreadsheet macros developed in-house that are difficult to maintain and difficult to upgrade as new protocols emerge. These are then supplemented by hardware based testing that is difficult to make comprehensive for worst case scenarios. Sophisticated COTS network design and verification tools are now available that deliver rules based automation, timing analysis, and verification (Figure 6).
Easy implementation of customizations and maintenance remains a strong requirement in the E/E systems domain as companies tailor processes to fit their specific needs. While IP capture and protection remains vital in some areas, especially harness manufacturing, this broad trend reflects both the tendency for good practices to migrate through industries and a sharper focus on core competencies such as engineering innovation.
Figure 6: COTS data communications network design and verification tool.
Conclusion
Several factors impact ‘make or buy’ analyses. All these factors apply to deciding between COTS and in-house E/E systems development software. In the E/E domain the decision now is usually to ‘buy’. COTS tools are widely deployed, driven principally by their cost advantage and maturity, including mechanisms supporting easy customization and IP protection. These capabilities help companies to manage challenges such as security and the desire for sharper business focus. This trend matches the pattern observed in other domains. It is likely to accelerate as further economies of scale accrue, enabling COTS suppliers to deliver yet more powerful products. And as COTS tools proliferate, the cadre of familiar users and associated ecosystem will also grow, further reducing the attraction of proprietary software development.
Nick Smith is Vice President of Business & Market Development for the Siemens Digital Industries Software’s Integrated Electrical Systems segment (IES). He leads a team responsible for IES’s go-to-market activities worldwide. He joined Siemens Digital Industries Software as part of the merger with Mentor Graphics in March 2017. Nick joined Mentor in 2001, holding several marketing and product management positions there. Previously Nick worked for Raychem Corporation (subsequently Tyco) in UK and USA, principally in the automotive, aerospace, defense & microelectronics industries. Nick holds a Master’s degree in natural sciences and Ph.D in laser physics from Cambridge University UK, and an MBA from Bristol Business School UK. He is married with two grown up children.
