Hi-rel component tracking needs common ground

Stock management is crucial in any industry, but when the end-product falls into a high-reliability sector, such as military, medical or aerospace, then the stakes are even higher. Qualifying components for use in a hi-rel application is a critical step and managing the supply and deployment of those components once qualified is equally critical, write Mattias Ericson from Omnisys Instruments and Robert Huxel from Altium Europe.

HIFAS Correlator ASIC

HIFAS Correlator ASIC

For Omnisys Instruments, a Swedish-based company operating in the space industry since 1992, supply chains and life-cycle management are an integral part of their operation; having been involved in several major projects for Europe’s scientific and space industry, including the development and production of satellite power supplies, autocorrelation spectrometers and water vapour radiometers.

These complex systems comprise many design disciplines, including advanced analogue, microwave and RF design, as well as Asic and embedded software development.

Designing for any harsh environment incurs careful component selection, which isn’t always as simple as selecting a component intended for that environment. Invariably, ODMs like Omnisys will impose their own constraints, putting systems through carefully designed ground-based qualification procedures that not only verify components intended for harsh environments, but also open up the possibility of using COTS (commercial-off-the-shelf) components, through qualification.

Recording and monitoring the results of these procedures is only part of the task, however. It then becomes necessary to apply that same rigorous control at every point of the product’s lifecycle, without impeding productivity.

Commonly, ODMs will employ some form of database to record a BoM; even a simple spreadsheet can provide a central repository of information. However, design teams necessarily need to work independently while drawing on a common source of information and, here, a simple spreadsheet may soon become unwieldy.

A popular alternative is to use a more comprehensive database solution; one that provides more than just a spreadsheet. Typically, design teams require a method of recording not only the components available for use (or those not recommended for new designs), but also where those components are used, in what volume and their production timescale. In addition, as design never stands still, it is advantageous for any such system to also offer a record of design iterations — normally referred to as revisions.

In the design domain these features are often provided by a combination of popular, open-source systems such as the versioning and revision system, Subversion, and a method of creating a web-based interface to databases, such as DBLib. Combining these technologies isn’t straightforward, however, and even though they are supported through APIs to design environments, integrating them seamlessly and in a way that fully supports collaborative design can be challenging.

This was the case with Omnisys, which until recently used Subversion (SVN) and DBLib solutions to support its design environment of choice, Altium Designer. Omnisys has been a proponent of Altium’s technology since its early days, and has built up experience of the benefits and problems involved with combining open-source and proprietary solutions.

One major disadvantage of the incumbent solution was a simple method for deprecating components within SVN; an important feature in lifecycle management. The lack of documentation was also a hurdle when configuring and maintaining the system. In addition, it was difficult to accommodate design collaboration, impacting productivity negatively.

As a proponent of Altium Designer, it was a logical evolution for Omnisys to become an early adopter of the possible solution to the problems posed by the SVN/DBLib combination: Altium Vault Server.

The philosophy behind Vault is the creation and management of design-reusable items, stored in a centralised repository for access by an entire design team, with version control and lifecycle management. As such, it becomes must simpler to create, deploy, deprecate and generally manage components once qualified (or excluded) for inclusion in new designs. It also allows the entire team to contribute to the Vault, providing greater design collaboration and increasing overall productivity.

The use of a central repository allows multiple members to check data files in and out concurrently, while maintaining a complete revision history of any and all changes made. In this way, any single design is stored as a series of revisions, such that no individual version of a design is ever ‘lost’ or overwritten — either inadvertently or with intent. This creates an inherent audit trail of all changes made, by whom and when, as well as recording the intention behind any changes.

Once design projects have been fully released for production the files are made available to the supply chain side of the repository; it is here where component definitions meet design documents, providing the purchasing department with all the data needed to turn the production handle.

In this way, the Vault provides a common ground between design and supply chain demarcation; allowing assemblies, sub-assemblies, components and complete systems to be referenced with their own unique identification and a ‘production passport’. The abstraction from system to component provides maximum transparency, all handled seamlessly by a centralised repository of carefully indexed design files.

An important attribute of adopting a Vault-driven design philosophy is the confidence it gives design managers; knowing that once a component has been selected and placed into the Vault, that component’s credentials will follow it around permanently. Its inclusion in the Vault becomes the component’s ‘stamp of approval’ for being selected for new designs. For a company concerned with high-reliability, knowing that the component selected has already been approved removes the risk for costly in-service failures.

For Omnisys, the process of component qualification isn’t as simple as it perhaps appears; the selection of space-qualified components isn’t a shortcut to building a list of approved components. In fact, every component approved for new designs must be proven despite its qualification. Interestingly, this doesn’t exclude commercial components; COTS is a major potential cost-saver for companies like Omnisys, but it cannot be confused with low-cost. True, the cost of COTS is intended to be lower, but the important factor is building confidence in a component and its supplier, to the point where it can be approved for use in systems destined for one of the most extreme environments.

This process requires the component in question to carry with it its own ‘history’ as it progresses through the system, ultimately with the intention of adding it to the approved component library within the repository. Previously, using SVN and DBLib, this wasn’t as straightforward as perhaps it could have been and even when added it wasn’t always easy to release (or, in fact, remove) that component to/from the design team’s library. Using Altium Vault Server, the qualification process is easily monitored and controlled, allowing the progress to be monitored, updated and shared.

Another feature of Altium Vault Server is its integration with the distribution channel; allowing component availability to be checked and tracked in real-time — with live data — makes sourcing even simpler. This affords SMEs like Omnisys the visibility it needs to schedule production runs with suppliers, and highlight any supply chain issues that may affect that schedule earlier than previously possible.

The seamless integration of Altium Vault Server with Altium Designer also promotes simpler system management; it now becomes easier for an administrator to control access to the Vault and authorise team members to become contributors.

Design collaboration and concurrent design are terms often used to describe approaches intended to address the complexity and cost of new product development, yet they fail to address the fundamental challenge of enabling such approaches.

Through the adoption of a centralised design repository, architected to support not only concurrent, collaborative design, but also the entire lifecycle management of product development, ODMs like Omnisys are now able to implement their exacting qualification procedures across an entire design team seamlessly. This provides not only a more productive design environment, but elevates the selection and management of critical components to become a team activity, thereby relieving another possible pinch-point in the design cycle.

Mattias Ericson is a design engineer at Omnisys Instruments AB and  Robert Huxel is industry specialist, enterprise solutions, at Altium Europe.

Leave a Reply

Your email address will not be published. Required fields are marked *