As part of the UUT description, its intended to describe all the sub components used as a parts list. This can then extracted as the Bill Of Materials (BoM) or just components for any FMECA type exercise. ATML Hardware descriptions have always allowed a component subcomponent structure to be defined. In most cases their original objective was to allow UUT is made out of LRU (line replaceable units) which are themselves made up of SRU (shop replaceable units). Each one of these is considered a UUT (at some level) and may have its out UUT Description.
For the ATML demonstrations the UUT is built directly from common components resistors capacitors transistors etc. Describing these components is a edge use case for the ATML hardware descriptions. What is described below will be changed in future releases of the 'dot' standards and therefore replicating its use should be considered carefully.
The basic concept is we are trying to represent the following components and values with enough detail to both identify component for build and repair and allow us to describe the complete schematic, though a netlist.tabl
Need to identify the component, give it a name and identify what type it is.
To start with every c:Component must have an ID, but an ID is only unique, and has meaning, inside the ATML description, to provide a 'permanent' name we also need to fill in the designator. We could chose only to fill in ID (the mandatory attribute), this would require any client program to use a rule to default designator to ID if not present, since this would restrict its use, a better approach would be to duplicate the information.
The dilemma this leaves is how to identify a component such as a 12K resistor. Initially we considered ModelNames of "12K" or "resistor, 12K". This required some parsing of the component to identify what type it was. It was also felt that there must be some 'other' standard fro identifying component parts perhaps from the CAD or drawing , but none came to light, during the demo.
The resultant solution used, is still unsatisfactory, it uses the Identification number to hold the fact its a resistor (component) and its value 12K. and since ModelName is mandatory uses a component value to identify the part e.g. 12K . If a component standard could be identified then that should be used as the ModelName. In the future we expect to create a special hardwareitem type just for components that allows us to better define these types of hardware components. In the mean time we use what we can.
Identifying the component solves half the problem, however the UUT description is also suppose to represent the schematic, or at least point to point connections. In order to do that we have to provide named ports with each of our components. In essence we can define a set of ports for any HardwareItemDescription type using its c:Interface elements. To do this each (sub)component is made a uut:HardwareUUT type and Interface ports provided.
In the UUT description the names of the ports on components are almost irrelevant, although this is true where the ports represent symmetrical components, e.g. a resistor or capacitor can be inserted anyway around, however for asynchronous components e.g. NPN or switch the Ports and pins have to be matched.
Note: In the example a universal matching between port and pins was not achieved, the best we did was be port name e.g. in/out switch and e,b,c for NPN transistor
This identification problem only exists for basic components, if we consider the IC components, here there model already defines there associated pins, every IC has a pin numbering system. In this case we mealy identify a Port for each pin, with a specific connectorID and pinID. In the example It uses a connectorID the same as the component ID which has the effect of defining a corresponding connector.