Quantcast
Channel: Capital – Paul Johnston's Blog
Viewing all articles
Browse latest Browse all 33

In Capital: Ease of Use, EEEEE of UUUUUUU, E’s of U’s

$
0
0

Capital software covers the automotive electrical design process from early conceptual architectural design through product engineering. And onwards too through manufacturing engineering to manufacturing assembly. In this entirety one would expect sophistication is needed the ability to handle complexities, nuances and variations. Doing this while sustaining a user-friendly reputation has to be achieved to keep users happy.

 What do you want?

Finding your way around functionally rich software takes a combination of knowledge and inclinations. There are lots of methods writers of software utilize to make that journey from first impression to lasting familiarity a smooth transition. A focus aspect of the design of computer systems is known by the acronym HCI – Human Computer Interaction. To most consumers of an application – you are more interested in the benefits of using the system rather than how clever the system is in terms of how it interacts with you. Your judgment of whether software is good or not is quite rightly not usually a conscious one – you should not have to debate the issue. Can I get my job done and is the experience one where it is easy to do so?

Visualization.

When you are designing a transportation platform, there can be hundreds of signals, thousands of wires, hundreds of wire harness part variances, oodles of options, dozens of Electronic Control Units, a smattering of ground paths, a maelstrom of engineering changes to many scores of diagrams. It helps that you can pick out the things that you want to concentrate on quickly. In software applications – if visual cues are not obviously different it will be difficult to distinguish between things you as a user really do need to discriminate between. In Electrical platform engineering the visuals – the release prints are really important. Those pictures are summaries of many thousands of words.

Hence when drawing standards are being decided, your company may choose to identify wires for power and ground by different and obviously distinctive colors on the schematic. Furthermore when drafting or generating service and technical publications diagrams using Capital Publisher you can see a case in legibility and accessibility for rendering these schematics showing the jacket cover of the wires in the pathways of the wires across the diagrams.

Demo Data: Look at both. Which one catches your attention better - left or right?

Conductivity pathways are more prominent if shown in different appearances.

Another example of reducing the ability to misinterpret your data as visualized on the electrical diagrams is the technique of tabooing names or elements of names which have potential to confuse. So, for instance it is common to have letter “O” disallowed in reference to wire naming, or naming of other objects such as devices, harness mechanical items or cavity names. This obviates the confusion between zero (0) and (o or O). Similarly Z, z, I (upper case i), l (lower case L) are frequently not included in permitted names in order to avoid confusion with numerals 2 and 1. B may avoided because of similarity to 8. You pay attention to detail in the textual data you use.

Lookup lists in Capital – Project resources and rules and constraints.

This is part of the “prevention not cure” philosophy which leads one to favor creation of permitted lists of device, connector or harness family names – or leads to the applying of rules so that you must have the revision suffixes of your designs and diagrams – your child harness parts for example – correct by construction. It is best that there shall never be a hint of a question of a doubt in your mind about whether that is a dash or an underscore in the harness part number. And there will not be any room for doubt, nor a need to check if one or other or both are by rule excluded. That’s what correct by construction means and how quality improvements delivered.

The Capital User interface (and VeSys 2 too for that matter) has a multiplicity of these features. There are also some other really good practices for showing what you want to see (fade in and out of manufacturing process sub-assembly/module views in Capital MPM/TVM for example. Additionally highlighting of pathways, highlighting during for simulation, the trusty zoom to, a one-key open associated of sheets – all fast techniques of getting to your required sub-set of data quickly.

New things added in new versions – old stalwarts still serving you well.

My favorite recent addition was last year’s introduction of “show circuit” in Capital Integrator – an implementation of the Capital AutoView technology which came out of users’ welcoming response to a similar “show-me” rendering feature in Capital Publisher.

Cutting down on the amount of available information – de-cluttering – is for a lot of engineers an important aspect of being efficient. Just enough information is best. Too much will increase the risk of ignoring something significant. That’s why the Design Rule Checks provided as standard can be pruned back using Capital Project so not all of them run, or run and give indications action is imperative. And when you are examining with the output you can yet further filter to better prioritize your response and understand the importance of the feedback you are getting.

Filtering my design to establish which messages are caused by wire specification issues. Capital Library definitions are not yet ready

The display of Design Rule Validations for a schematic can be dynamically changed as you filter the list to concentrate on the important ones to you

Consistency of the “look and feel” and the detail of how you interact with the data sets has also also achieved through the different functional modules of Capital. You can expect to see the same Part Selection Dialog in Capital Harness Manufacturing Process Management as you use in Capital Logic for example. This means that wherever possible the short-cut keys, the print dialogs invocations are standardized and the benefit is that if your people have responsibilities which cut across traditional design cycle boundaries (the harness person is encouraged to explore the systems designs) there is a minimal training overhead – perhaps none in some cases.

Take a test for which there is no pass mark.

It has been remarked by a colleague recently that my approach to using Capital is to concentrate more than average on using the right mouse button, and in terms of keyboard entry I find my way around via the tree view filter a little more than most other users do on average. Also I use the ALT- key combinations to invoke functions more than most. So as an experiment – given that I am less inclined to make use of toolbars, I took a toolbar for adding diagram objects into a schematic from Capital Design and pasted it into a blank page and tested myself as to whether I could “run the table” of getting the function of each of the icons.

16 Icons on a Toolbar in Capital, yo ho ho and a bottle of devices

16 of many functions collected in a toolbar. In the Capital Logic application you can simply rest your cursor over the item and be told what it is by a call-out message

Bear in mind I am an expert at this so I should do pretty well you would think. So out of sixteen, I guessed correctly thirteen. If you are trying this for yourself and bagged a superior count, well done for your achievement if you had more than me – and for reasons explained later, well done if you had fewer correctly identified than I.

The item furthest to the right is the icon for adding graphical elements like lines, circles and other shapes to the drawing. It was the three to the left of that which I gave up on being able even to guess at. The drafting purpose of those icons are actually: to add overbraid; edit/add assembly; and finally to make/modify a block.

Now comes my excuse for getting some wrong. Not that the assembly icon (looks to me anyway) like a blue audio cassette from late 1970’s. Nor either shall I complain that for some simple picture of an already abstract concept – like one of those I got wrong was add a block – it is difficult to get an effective further abstraction of an already abstracted concept. There’s only so much help a picture can give you. Try designing an icon denoting phenomenology and you’ll see what I mean.

Mix tape not icon

No – here’s my excuse – those three are ones that I seldom use. Most of the work supporting customers is done where blocks, over-braid definitions and assembly items are not used. Icons are as much memory aids. Not for initial cognition but re-cognition. That’s my excuse and if you only have a few out of sixteen correct then I guess you don’t draw schematics with Capital Logic much at all. When you do get habituated to abstractions – it doesn’t take long to adapt to EEEEE’s of UUUU’s conventions – you’ll do well or better than I did.

Answers to the test

Here are my answers so you can check your own if you want to play along. I allowed myself 3 seconds only for each answer – any longer indicates a greatly reduced chance of guessing right. And there are no prizes for beating me, other than the glow of satisfaction knowing you did better than someone who may be supposed to know all 16 via subliminal fanaticism.

  • Make parameterized device & characterize pins later
  • Insert plug
  • Insert inline
  • Insert receptacle
  • Ring terminal
  • Add splice
  • Add net conductor
  • Add wire
  • Add highway
  • Add shield termination
  • Daisy chain something … hmm multicore shields phew got it.
  • Make multicore
  • Don’t know (overbraid)
  • Don’t know (assemblies)
  • Don’t know (add/edit block)
  • Draw graphic shape with no electrical content/meaning

Viewing all articles
Browse latest Browse all 33

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>