Altium NEXUS Documentation

Status message

Данная страница доступна на русском языке для версии Altium Designer 20.2: перейти

Altium 365 Workspace - Управление проектными данными

Created: 03.08.2021 | Updated: 07.09.2021

Your connected Workspace, in conjunction with Altium NEXUS, brings support for projects. Workspace projects target the development stage of the project lifecycle, simplifying the creation and ongoing workflow for version-controlled projects. Centralized storage under the control of the Workspace also enables this feature to be a foundation for other collaborative services.

Some key benefits to using Workspace projects are:

  • Simplified storage. No need to make decisions about storage locations. Backup and other basic services are taken care of.
  • Foundation for collaborative features.
  • Enforced version control.
  • Advantages of a dedicated commenting system.
  • Notifications and status. Document status including local modifications is visible to entire design teams.
  • Concurrent PCB design works without any complex setup.
  • Ability to share the project with multiple people for editing, or for viewing and commenting only.
  • Full functionality when using the Project History feature, including VCS-related commit events.

Management is performed through the Projects page of the Workspace's browser interface. New projects can be created through this interface or through the Create Project dialog in Altium NEXUS. Alternatively, an existing project (a local project, or a local project currently under external version control) can be quickly made available to the Workspace.

You can also access a detailed, CAD-centric view of the project which offers Design, Supply, Manufacture, Activities, and History view options:

  • Design – display and navigate source project design documents, view design object properties, and place review comments. This view uses the Web Viewer interface. This view is for the latest version of the source project data, rather than a specified release from that project, and so could be considered to be a work-in-progress (WIP) view. You can view the base design or any defined variant thereof.
  • Supply – interactively examine work-in-progress (WIP) BOM data extracted from the design documents, including entries for Manufacturer and Supplier parts data derived from a project's populated ActiveBOM document.
  • Manufacture – view the releases for the project. Access is provided for opening the full release data, or a specific assembly package, which will be presented on a separate tab through a Manufacturing Portal. From this portal, you can view and navigate the released file data, inspect the BOM, and view and comment on the snapshot of the design itself; the source for that released data. From either the Manufacture view or through the Manufacturing Portal for a specific release, you'll have access to controls for downloading manufacturing data at various levels of granularity (from full data set to individual generated output file).
  • Activities – search, view, and access workflow process activities that apply to the selected project, such as design reviews. Use the sub-tabs for a selected activity to see its live flow Diagram, related Data, and event History.
  • History – browse a progressive timeline of major events relating to the project, including its creation, commits, releases, clones, and MCAD exchanges. Each time a supported event happens in association with the project, that event is added to the timeline as a dedicated tile with various actions supported where applicable. For more information, see Management of Projects – Project History.
The beauty of Workspace projects is that they are version-controlled by default, and can be collaboratively worked upon without having to worry about shared drives, servers, agreements, etc. Version control is handled courtesy of the Workspace's built-in Git version control service.
Read about Workspace Projects.

Reusable Design Circuitry

Being able to re-use design content is something that all product development companies want, and can greatly benefit from. Not only does reuse save time, being able to easily re-use a section of a previous design means that all the qualification and testing of that part of the design is done. Design reuse is much more than copy and paste though, true reuse requires the content to be locked down so you're guaranteed that it is the same as before. No quick edits to change the color of a component or a tweak to a resistor value, working with reusable content must be like working with off-the-shelf components; place the content, wire it in, and it works just like it did last time.

Altium NEXUS, in conjunction with your connected Workspace, caters for the ability to create Managed Schematic Sheets (often termed Managed Sheets) in that Workspace. Such Items can be created directly from within the Workspace. Once a Managed Schematic Sheet Item has been created, it can be reused in future board-level design projects.

A managed sheet is a standard Altium NEXUS schematic sheet containing components and wiring, that has been stored in your Workspace so it can be reused in other designs. It is edited like any other schematic sheet. The managed sheet concept is not limited to a single schematic sheet, you can place a managed sheet in your design that is at the top of a tree of other managed sheets.

Managed sheets differ from Device Sheets in that they are stored within your Workspace, where device sheets are stored in a folder on a hard drive. As such, they enjoy the benefits attributed to Workspace content, including simplified storage, secured integrity, and built-in version control.

By moving from device sheets to managed sheets you can be sure that the revision of a managed sheet that you use in a design can be easily identified and traced back to its source whenever needed. And because it is Workspace content it can be revised and updated when needed; and the usage relationships can all be traced, both down to the components on that sheet, and up to the designs that use that sheet. This ensures you have all the information needed to decide if that revised sheet must be pushed through to existing designs, or if a particular design must continue to use the previous revision.

The ability to use Workspace components to build larger design building blocks enables the design flow to become ever-more streamlined, and at a higher level of abstraction. The designer, just like picking parts off a shelf, reuses these managed sheets of design functionality as constituent components of the bigger design project. And the more managed sheets of such circuitry that have been created and released into your Workspace, the more functionality the designer has access to, which in turn boosts productivity for subsequent designs.

Components

Altium NEXUS, with its unified design approach, has traditionally used a component model that extends across all aspects of the electronics design process. However, to seamlessly fit the process of electronics design into the encapsulating product development process as a whole, this model needs to evolve – extending to cover other aspects including other design processes (in particular MCAD and Industrial Design), as well as business processes (such as procurement and manufacturing) that intersect with the product development process. This evolved object model is known as the Unified Component Model.

This component model effectively maps the concept of a design component – in the traditional electronics design arena – to the component as seen by the rest of the organization in the bigger 'product arena'. A truly 'Unified Component' model that not only represents the component in the different design domains (Schematic Capture, PCB Layout, Simulation) but also facilitates choices of the desired physical components – real-world manufactured parts – at design-time, offering a significant improvement in terms of procurement cost and time, when manufacturing the assembled product.

Under this modeling paradigm, the design component, as seen by the designer, is separated from the Manufacturer and/or Vendor parts. This information is not defined as part of the component. Instead, Part Choices are used to map the design component to one or more Manufacturer Parts, listed in a Part Catalog, which in turn can be mapped to one or more Vendor parts, allowing the designer to state up-front, what real parts can be used for any given design component used in a design.

These components, along with their part choices, are stored in your connected Workspace – one centralized secure location for all your design data, accessible for your entire design team.

  • Single source of component data – with a Workspace accessible for the entire team, engineers can source up-to-date and standardized components from one secure location, get real-time supply chain data, and use parametric and faceted search to find the exact components they need.
  • Company-certified design components – components are released into a Workspace for re-instantiation into a design project. Revision-controlled and lifecycle-managed, a company can authorize the 'set' of components that can be formally used by their designers.
  • Design-time choice of physical components – for any given component, you can choose which manufacturer parts can be used to implement that component when assembling the board.
  • Real-time supply-chain information – fed back from the aggregate parts database of the Altium Parts Provider (which itself interfaces to and gathers the parts from enabled Suppliers) to let the designer know the current costing and availability of the chosen parts, and from all vendors that sell those chosen parts (as defined in the Workspace's local Part Catalog). This information can be added to a component at any moment, including after release of this component – without directly editing it and hence without impacting designs where it is already used – and then be used as part of a Bill of Materials.
  • Use of Component Templates – apply parameter and component taxonomy-based templates, so each new component type automatically has the correct BOM-compliant parameter set in addition to automating the correct naming, revision, and lifecycle schemes.
  • Concurrent editing of the library – as the Workspace library is essentially a set of Component Items hosted by this Workspace, multiple users can be editing or creating new components for the Workspace library independently, without having to wait when other users will finish the work on their side.
  • Where-used Component Traceability – components can be traced all the way through usages: if a part goes obsolete, you can explore in which designs it was used to know which ones need to be updated. If a symbol or footprint has an error, you can see all the components that use that symbol and footprint so you can fix them.
  • Component Lifecycle Validation – if a component is in an “end of life”, “obsolete”, or “abandoned” state, you will be warned before trying to manufacture boards that use it.
  • Component Models Reuse – a component can be thought as a 'bucket' into which all parametric information and domain models is stored, including schematic symbol, PCB footprints, and simulation models. A component doesn't contain the domain models themselves but rather links to the relevant model Items that are also in a Workspace, so a single domain model can be used by multiple components. If a model changes, you'll be suggested to update all components that use this model, and this ensures that no component will use an out-of-date model.
  • Direct Component Editing – if a component needs to be edited, you can open it for editing directly from within your Workspace. A temporary instance of the Component Editor allows you to edit all aspects of that component, including modifying its referenced domain models without a file-based document in sight.
  • Requests of new components – an engineer can submit requests for new (or missing) components to the dedicated librarians and get notified when this component becomes available for use in designs by the requestor and other engineers in the company.

Templates

Altium NEXUS, in conjunction with your connected Workspace, caters for the ability to create and manage a variety of templates for use in and by, your board design projects. The following template types are supported:

Once a template has been released to the Workspace, that template can be reused in future board-level design projects.

You even have the opportunity to create Project Templates. Such templates stored in your Workspace can include the common document and file types that make up a project, as well as additional reference documentation and configuration files.

Management of all templates – both Workspace and local (file-based) – can be performed from a single, convenient location – the Data Management – Templates page of the Preferences dialog in Altium NEXUS.

Board Design Release

Altium NEXUS provides powerful, high-integrity board design release management. The board design release process is automated, enabling you to release your board design projects without the risks associated with manual release procedures. When a particular project is released, a snapshot of the design source is taken and archived along with any generated output – which represents a tangible product that is made from that design project and sold by the company. Release data is stored in revisions of the relevant project-related Item in your connected Workspace:

  • PCB Project Design Item – the snapshot of the design, including all source documents. Released into a separate Item in the Workspace, allowing you to keep your valuable IP aside from the generated fabrication and assembly data needed by external parties to build the product.
  • PCB Fabrication Data Item – the data set required by the fabrication house for manufacture of the bare board.
  • PCB Assembly Data Item – the data set required by the assembly house in order to populate the bare board with specified components, in accordance with a Bill of Materials. A unique Item is used for the base (fully populated) design and each defined variant for the design (assembled variants).

The overall result is the highest integrity board design release management possible. Not only is your actual design project tightly monitored, backed-up, and managed under the Workspace's native version control, but also too, the releases of its data in a similar manner within the target Workspace – robust, safe, secure.

  • Integration with version control. If your project is under version control, then the system requires all files to be checked in and up to date before releasing. This ensures that no "private copy" of an essential design document is ever allowed to sit on an engineer's hard drive – with the potential of becoming lost. This simple rule can save hours down the track in costly searching for the right set of design documents that were used to generate a released product.
  • 'One-shot releasing'. The system only allows you to release once to any given revision of a targeted Item. In fact, a successful release results in committing (storing) the release data in the referenced Item Revision, then closes that revision. No further data can be generated and released into that same revision.
  • Automated and repeatable design release process. One-touch releasing – no manual stages or risks. From taking the snapshot of the design files, through validation, and output generation, there is no interaction. If a part of the process fails, the release fails. Simple as that. And you get to review all generated data before the final committal of the release data into the Item Revision in the target Workspace.
  • Ability to validate the design as an integral part of the design release process. The release process works from a 'locked down' snapshot of the design source (including dependencies) and pre-release validation is almost sure to have been performed prior to initiating release. But for additional peace of mind and to ensure the integrity of the design data, you can optionally add validation checks into the release process 'flow', through appropriately-configured Output Job Configurations. Standard ERC checking for the source schematics and DRC checking of the PCB, but also the ability to check that the source project and PCB are in-sync, and comparison of footprints on the board against their source library to ensure they are up-to-date, and matched. The release will fail if any validation checks are not passed successfully.

    If you're using Workspace components in your design, you can add and configure an additional validation check – Component State Checking. This checks for components that are in restricted states. As part of this configuration, you determine the action to be taken for each currently defined state, of each currently defined lifecycle definition in the target Workspace; no action, a warning, or generate an error. The latter will prevent the release of the design. In addition, running the check will generate a handy HTML-based report, allowing you to see at-a-glance which design components are not in valid states.
    You can also include an Environment Configuration Compliance Check. This provides a means to conclusively test and enforce the use of company-authorized data elements in a design. Simply put, if you are not using data items permitted through the environment configuration available for use by your assigned role, the release will fail. This prevents a 'loose cannon' approach to design and ensures adherence to, and compliance with, the working design environments determined centrally at the enterprise level. For more information on environment configurations, see Environment Configuration Management.
  • All generated data files from the design release process can be optionally prefixed with the Item ID and the Item Revision ID, ensuring there can be no ambiguity as to which revision of which Item the data is to be used to build.
  • Publishing. Offering the ability to publish release data directly from the connected Workspace to a shared storage medium, such as Amazon S3, FTP servers, Box.com, or a simple network-based folder. This facilitates easy sharing of Workspace data in a secured way, without providing outside parties access to your Workspace.

The Project Releaser

The release process itself is performed using Altium NEXUS's Project Releaser, the user interface to which is provided courtesy of a dedicated view – the Release view.

The Project Releaser caters for all types of PCB project – local/non-version-controlled, under external VCS control, or under the native version control of a connected Workspace – by offering two modes of operation:

  • Online Mode – releasing all generated data to revisions of Items in a target connected Workspace. You don't even have to remember to increment Item Revisions, it is all handled for you. And if you have a process defined for releasing to a PLM instance through the Project Releaser, starting that process will add an additional stage to the view for doing just that.
  • Offline Mode – releasing all generated data into a folder-based structure, which can be optionally wrapped up in a single Zip file.

With the Release view in Online Mode, the release process is a staged flow, with the entries on the left-hand side of the view showing you at-a-glance, which stage you are currently at:

  1. Configure Server Release – this stage of the release process is where you specify the type(s) of data that you wish to generate (Source Data (always generated), Fabrication Data, Assembly Data (for base design and each detected variant)).
  2. Validate Project – this next stage of the release process is run automatically when one or more Validation-type reports are detected in assigned OutJob file(s). All defined validation output generators, defined in an Output Job file assigned to the data item being released, are run.
  3. Generate Data – this next stage of the release process is run automatically. This is where all other outputs – defined in the OutJob file(s) assigned to the included Data Items – are run, to generate the data to be released into the relevant target items in the Workspace.
  4. Review Data – with all validation checks passed, and output data generated, this stage of the release process allows you to review the generated data.

    If you choose to use the Prepare & Release or Prepare & Release & Publish to PLM commands (from the menu associated with the button), the Project Releaser will not pause at the Review Data stage.
  5. Upload Data – after confirming the release in the previous stage, this next stage is automatically entered. It simply presents the progress of data upload into the revisions of the relevant data Items in the target Workspace.
  6. Execution Report – this is the final stage of the process, providing a summary of the release. Navigation links are provided to quickly browse to the generated Item Revisions in the Explorer panel. If you have accessed the Project Releaser as part of a process to release and publish to a PLM, then the button will be presented. Click this to continue the underlying workflow for the process, to publish to the PLM.

    If you choose to use the Prepare & Release & Publish to PLM command (from the menu associated with the button), the Project Releaser will not pause at the Execution Report stage, and no button will be presented.
  7. Publish to PLM – this stage is only present when running the release under the relevant activated process (for releasing and then publishing to a PLM). This stage is entered automatically when the button is clicked in the previous stage (or entered directly if the Prepare & Release & Publish to PLM command (from the menu associated with the button), was used). The Login Credentials dialog will appear. Enter the Username and Password for your PLM instance, and select the PLM Template you want to use (which appears in the form <PLMInstance>:<PublishingTemplate>).

    Note that your PLM instance login credentials are only required for the first time you publish to that instance. These will then be stored with the Workspace. After that, any publishing of that project to that same PLM instance will proceed directly, in accordance with the defined workflow and chosen publishing template.
    If you're publishing for the first time and part numbers (on the PLM side) are not yet associated with the project, those part numbers will be created in the PLM and associated with the project as part of that initial publication. You also have the ability to define component entries for Workspace components in the PLM instance, as part of the publishing operation – to get a BOM of components within the PLM (optional, based on the publishing templated defined and used when publishing the project to the PLM instance).
If your project currently has no Output Job file(s) associated with it, the Project Releaser will detect this, and you will be asked if you wish to create default ones. In addition, the Project Releaser will detect defined variants for your design and create Assembly Data sets for each, ready for release.
The system naturally prevents any modification of design files between preparing the release and releasing the data to your Workspace. If you do change design files in any way, the release process will terminate, and you will return to the initial stage, prior to release preparation.

With the Project Releaser, you'll be able to generate your manufacturing data with simplified ease, and with the highest integrity. And you'll also be able to survey the fruits of that generation before you commit to finalizing the release (viewing Gerbers/ODB++ data in the CAM Editor for example), ensuring that the data you have generated is exactly the data required to get your board manufactured on time, first time.


Publication of Released Data

For released data generated from a board design project (PCB Fabrication Data, PCB Assembly Data, and PCB Project Design Items only), you have the ability to directly publish that data from your connected Workspace, or Output Job, to a storage space, such as Box.com, Amazon S3, an FTP server, or a simple folder location on a shared network. In terms of distribution and collaboration, this provides an unparalleled advantage in a world where the collective members of the overall 'product team' - the design team, the manufacturing team, and all others involved in the process of getting a product from thought to reality – are often dispersed around the globe.

Publishing is a matter of defining a Publishing Destination and then uploading the released data for the required Item Revision to that destination. From the manufacturing plant in China, to the design teams in Kiev, Stanstead Abbotts, and San Diego, and to the Project Director in-flight somewhere across the Pacific, everyone that needs to know about the new release can be invited with a link to the published folder – shared (and controlled) access to view, discuss, and utilize the data with which to build the Item.

Обнаружили проблему в этом документе? Выделите область и нажмите Ctrl+Enter, чтобы оповестить нас.

Связаться с нами

Связаться с нашими Представительствами напрямую

We're sorry to hear the article wasn't helpful to you.
Could you take a moment to tell us why?
200 characters remaining
Вы сообщаете о проблеме, связанной со следующим выделенным текстом
и/или изображением в активном документе: