NFS_2_1PLM Integration Improvements_ANS
The NEXUS Server PLM Integration capabilities have been further refined to improve the handling and transfer of component data with external enterprise systems. This includes interpretation of company supplier information (Part Choices) and unit-aware parameter data, and the relationship between PLM instance configurations and NEXUS component templates. The performance and memory footprint of the component synchronization engine has also been significantly improved.
Part Choice handling
The propagation of component manufacturer Part Choice data from an external enterprise system (such as a PLM) to the Altium Server now avoids the possibility of data duplication or unwanted removal. Where component data is brought into the server directly from the external system or via a CSV file, the creation and/or modification of Part Choice entries is handled intelligently, based on the current conditions and data history:
- If a component Part Choice entry being imported already exists for that server component, it will not be duplicated.
- If a server component Part Choice entry was added within the server (not imported), it will not be replaced by imported Part Choice data. An imported Part Choice will be added as a new, additional Part Choice for that component.
- If new Part Choice data is imported for a component, it will replace the previously imported Part Choice entry for that component.
In summary, other than respecting a component's existing non-imported Part Choice data, the Part Choice data imported from the external system will determine the server component Part Choice entry.
Component parameter data may be brought in to the Altium Server from a CSV data file, exported from the enterprise system, using the server's supplied CSV-Import tool – note that only a single Part Choice dataset per component is recognized. In the example image shown below, the input CSV file does not include Part Choice data (Manufacture Name
and Manufacturer Part Number
parameters) for PLM entry CVS-RES-1001
(the 10k
Resistor), so this is not added to the server component. In this example case however, a Part Choice entry (Vishay
) has been manually added to that server component from within the NEXUS Explorer panel.
If Part Choice data for that component (CVS-RES-1001
) is included in a subsequently imported/synchronized CSV file, as shown below, the new Part Choice entry (Rohm
) will be added to the component – since an existing 'native' Part Choice entry cannot be replaced by imported Part Choice data.
If a following imported/synchronized CSV file has new Part Choice data for the component, as shown below, that Part Choice data (Yageo
) will replace the Part Choice entry that was previously imported (Rohm
) – the existing 'native' Part Choice entry (Vishay
) remains untouched. Alternatively, if the CSV Part Choice data has been removed (blank MFR_..
entries), the import process will delete the existing imported Part Choice entry in the server (Yageo
).
Parameter Unit and Value handling
When component data are imported from an external enterprise system into the NEXUS Server, the interpretation accuracy and error handling of the server's automated parameter unit processing has been improved.
During a component data importation or synchronization process, any component parameters specified in the applicable Component Template as a unit-aware Type (Percent(%)
, Watts(W)
, etc) are interpreted accordingly. Since the formatting of the imported parameter values may vary widely, as they have been defined in an external system (such as a PLM), the server's unit-aware value processing caters for all likely formats and then correctly handle any errors.
The processing and error handling of parameter units can be seen when using the CSV-Import tool, for example – which could also be used for testing the compatibility of an external component data structure.
The below image shows an example case where a set of server components are updated by a CSV import file that includes the Power parameter for each component entry. The Power parameter values in the source CSV file use a range of formatting, and this includes a value error (62500x
) for the CSV-RES-1001
component entry. Prior to the data import, the server components did not include Power parameter data and were at their first revision (Revision 1
) – as shown in the upper Explorer panel.
The results of the CSV import process, as appear in the lower Explorer panel image (above), show the effects of both the unit-aware parameter interpretation and its error handling:
- A Power value has not been added to component
CSV-RES-1001
due to the CSV source data format error. - A new revision has not been created for component
CSV-RES-1001
(it remains atRevision 1
). - The Power value source formats for all other components have been correctly interpreted from the source data.
- New revisions have been created for the correctly updated components.
A subsequent component data import process, with a revised Power value (62500u
) for component CSV-RES-1001
, is correctly interpreted for that component – as shown in the below image. The server component data has been updated, creating a new revision (Revision 2
).
Component Template application
The data types and formatting used for component synchronization with external enterprise systems can now be controlled by a nominated server Component Template. Specified in the relevant configuration file, for CSV Import or a PLM Instance, the referenced server template will determine newly created component settings such as the Revision Naming Scheme, Component Lifecycle Definition, Parameter inclusions and Parameter Types/Defaults.
In the configuration file, the template reference is included within the CreateInfo
tags of the ToAltium
section for a particular component type entity.
<Entity altiumType="Resistors" plmType="ResistorSMT"> <ToPlm sync="false"> <Attributes/> <Options/> </ToPlm> <ToAltium sync="true"> <CreateInfo> <ComponentTemplate>CMPT-0001</ComponentTemplate> <!-- Naming Scheme and Lifecycle Definition not used if Component Template specified --> <RevisionNamingScheme>1-Level Revision Scheme</RevisionNamingScheme> <LifecycleDefinition>Component Lifecycle</LifecycleDefinition> <Folder>Components/ResistorsSMT</Folder> </CreateInfo> <Attributes> <ns2:Attribute attributeType="revision" primaryKeyOrdinal="1"> <ns2:Key>PlmPartNumber</ns2:Key> <ns2:Value>${attribute.PART_NUMBER}</ns2:Value> </ns2:Attribute>
This approach is particularly useful for managing the importation/synchronization of proprietary component parameters from an external system into the Altium server. In this case a tailored Component Template can be applied to interpret parameter data and set suitable default values, and also to specify the Lifecycle Definition and Revision Naming scheme for the created server components.
The following conditions relate to applying Component Templates:
- If a template is specified in the configuration file, it will overrule a template that has been associated with the target server folder. The configuration's template will also apply to a target folder that does not have a template applied.
- The component target folder specified in the configuration overrules the Default Folder setting in a Component Template. A folder path is a required entry in a configuration file (
<Folder>xxx</Folder>
). -
When a Component Template reference has been added to a configuration file it will apply to newly created components and their updates, but not to pre-existing components. In other words, the template is not applied retrospectively.
-
If a parameter is specified as an
item
ordynamic
attribute type in the configuration file and that parameter exists in the applied Component Template, the component parameter value will not be updated during component synchronization/import. For that parameter to behave in a 'dynamic' way during component synchronization (where a Value update does not cause a new revision), the parameter reference will need to be removed from the applied Component Template.
Arena Workspace compatibility
An Arena® PLM instance added to the Altium Server will now accommodate the Arena workspaces that are available for an Arena user account. An Arena workspace is addressed by a multi-digit ID that may be specified in the Arena instance configuration file.
The optional ID reference attribute is added as an PLM instance context in the preliminary Instance
section of the related configuration file.
<DMConfiguration id="Arena_Sample" version="1.0" xmlns="dm-config" xmlns:common="dm-config-common" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="dm-config dm-configuration.xsd dm-config-common dm-config-common.xsd"> <!-- Name of driver and URL for Arena instance --> <Instance> <Driver>Arena</Driver> <Url>https://api.arenasolutions.com/v1/</Url> <!-- Arena workspace id. Optional. If not set default user workspace is used --> <Context>12345678</Context> <!-- If enabled, sourcing information will be passed to NEXUS as Component Part Choices --> <!-- Default is false --> <EnableMfrDataSync>false</EnableMfrDataSync> </Instance>
The following conditions apply to working with Arena account workspaces:
- If a workspace ID is not explicitly defined, the PLM instance will work with Arena's default workspace for that account.
- The server will report an error if another PLM synchronization session is attempting to use a second workspace from the Arena user account.