Standards inject certainty into your working life. Last week I wrote about how the development of standards goes and the easiest pathway to adoption of them. Adherence to standards is an integral part of successful engineering. The most attractive standards:
- lack complexity – are easy to understand – clear and straightforward for a person like you
- turn out to be robust for the niche in which you operate – not a multi-purpose “all-things-to-all people”
- possess clear and open documentation – you can see a path to easy adoption
- meets a basic need – you know why you want it, what efficiency is brought to your business processes.
In short – there’s a lot of “what’s in it for you” in the standards hits – less so in the misses, the ones which do not get widely adopted.
The Design System Interface standard (.dsi hereafter for short; refers to the file name extension used) is an example of a niche standard which hit some sweet spots and has been popular as a design to manufacturing transfer format.
- The simple documentation to back up the ASCII format explains the concepts of data capture such that you don’t have to have post-doctoral research experience to make head nor tail of what is going on.
- You can look at a file in a text editor – it is plain text after all – and if the data is your data you can recognize pretty immediately what is going on in there – ‘oh look – there are the wires, down there are the terminals and down there are the bundle coverings for the harness and so on’.
- If you are a harness maker you struggle every day to take costs out of your manufacturing by harmonizing the way you treat customer’s data and this rather plain aggregation of data into sections contained the prospect of taking out a lot of manual steps and data rework. The need was obvious and the viability of this standard to be the solution to a lot of the problems was tempting.
The contents of a .dsi file can largely be interpreted with the naked eye.
Early adopters were followed by many later adopters.
Over time the format grew – the specification progressed to Version 11. The record descriptors were extended including to accommodate new sections covering the so-called modular or feature-based method of designing composite harnesses. Some sections of the format had fields added to the rows (you got the chance to express tape and tune coverings as part numbers for example). Those changes extended the number of fields expected in some records if you identified the version of the format as a later one. The sixth section in the format – the description of the components on the harness was by convention sorted into sub-sections for ease of use and ease of debug of the data – main node components comment lines then cavity components then comment lines and then splice details and then comment lines etc.
Oh, I didn’t mention already that this is a Mentor Graphics proprietary standard – openly available and widely transmitted and published. So it is time to do that now. 
Not all rosy in the garden.
Such format changes as described above were reasonably well handled in the Mentor Graphics import and export capabilities associated with this format. Customers who had written in-house custom code predicated on the format had to take on the task of validating their utilities still worked. Adherence to any standard comes with a little maintenance here and there.
With the release of new improved products in the CHS family to supplant the CapH Classic offerings, the way in which .dsi files were accepted into the new design tools is somewhat different. The use of the various Capital Harness Bridge techniques to interface from MCAD design systems superseded the need for a flat file transfer of data. With change management control becoming locked into the tool the old way of doing things began to look, well a little behind the times – even though CapH Classic was updated to contain a .dsi merge and change control capability. Capital Bridges has more advanced flattening capability from 3D data and the CHS suite uses xml formatted data to import/export operations. The X2ML format was developed as a next generation offering going beyond .dsi descriptor capabilities into the realm of 3D to 2D MCAD-ECAD data transition.
So why is .dsi so stubbornly holding on as a standard. Well, it is simple, widespread and known. It is good. A number of customers have written code to take advantage of the interchange format to standardize acceptance of customer data. Once you have invested in home-grown hand-coding it is hard to get off the habit. Especially if coding was done 7 years ago and all the programmers have since moved and nobody has a clue what the utility code you seem to rely heavily on actually does or how it does it! You might inadvertently be deciding based on inertia rather than benefits.
DSI is a good format but not absolutely pure. Remember the name “Design” System Interface – a format for transferring design information to manufacturing. Another debate I have had with customers is about using a design-side format to express not detailed design intent but manufacturing releasable bill of materials. DSI is close to a bill of materials format but there is a shortfall in a few key areas. Stay away. When wanting to extract BOM details into manufacturing tools – automated wire cutting machines and test equipment (for continuity and hi-pot tests for example) this straightforward format is tempting to use – however you have to realize the compromise involved.
Perhaps it is a sign of a good standard that it is misused a little here and there. The boundaries are pushed. However I feel compassion for the people who are making the square peg of the .dsi format fit into the various round holes. There are generally easier ways to acheive better results now – what with technology moving on apace in the last ten years. Even if you want to stick with carrier formats in external files – there are plenty of opportunities to improve the bridging capabilities of data.
But like with many opportunities to change there’s that question again – “what’s in it for me?” Unless you have a seriously broken process you might stick with what you are comfortable with for a long time before you realize your competitors moved away five years ago.
Web services based updates. Software as a Service. SOAP. Yes, things have moved quickly indeed. The latest technologies in CHS are impressive.
It's a flying spaghetti monster.
With a few deft touches the noodly appendages are made to look more like a harness manufacturing layout.
Flattened orthogonally from 3D import - disconnected mode of bridge.
A good standard loses ground after some better way of working comes along. Perhaps you are never home and dry because the competition in your industry changes so rapidly, and IT technologies re-invigorate the tools so frequently.