Free Trials

Download a free trial to find out which Altium software best suits your needs

How to Buy

Contact your local sales office to get started on improving your design environment


Download the latest in PCB design and EDA software

  • Altium Designer

    Complete Environment for Schematic + Layout

  • CircuitStudio

    Entry Level, Professional PCB Design Tool

  • CircuitMaker

    Community Based PCB Design Tool


    Agile PCB Design For Teams

  • Altium 365

    Connecting PCB Design to the Manufacturing Floor

  • Altium Concord Pro

    Complete Solution for Library Management

  • Octopart

    Extensive, Easy-to-Use Component Database

  • PDN Analyzer

    Natural and Effortless Power Distribution Network Analysis

  • See All Extensions

    World-Renowned Technology for Embedded Systems Development

  • Live Courses

    Learn best practices with instructional training available worldwide

  • On-Demand Courses

    Gain comprehensive knowledge without leaving your home or office

  • Altium 365 Viewer

    View & Share electronic designs in your browser

  • Altium Designer 20

    The most powerful, modern and easy-to-use PCB design tool for professional use


    Annual PCB Design Summit

    • Forum

      Where Altium users and enthusiasts can interact with each other

    • Blog

      Our blog about things that interest us and hopefully you too

    • Ideas

      Submit ideas and vote for new features you want in Altium tools

    • Bug Crunch

      Help make the software better by submitting bugs and voting on what's important

    • Wall

      A stream of events on AltiumLive you follow by participating in or subscribing to

    • Beta Program

      Information about participating in our Beta program and getting early access to Altium tools

    All Resources

    Explore the latest content from blog posts to social media and technical white papers gathered together for your convenience


    Take a look at what download options are available to best suit your needs

    How to Buy

    Contact your local sales office to get started improving your design environment

    • Documentation

      The documentation area is where you can find extensive, versioned information about our software online, for free.

    • Training & Events

      View the schedule and register for training events all around the world and online

    • Design Content

      Browse our vast library of free design content including components, templates and reference designs

    • Webinars

      Attend a live webinar online or get instant access to our on demand series of webinars

    • Support

      Get your questions answered with our variety of direct support and self-service options

    • Technical Papers

      Stay up to date with the latest technology and industry trends with our complete collection of technical white papers.

    • Video Library

      Quick and to-the-point video tutorials to get you started with Altium Designer

    What's the best way to make a library searchable? Parameters - Component Development Part 3

    David Read
    |  February 21, 2017

    It's one thing to make great components, but it's quite another to make them easy to find. In this blog I explain how we handle component parameters, why they are important and how we kick off our component development process.

    Looking at the discussion spawned from my first two blogs, I’ve a feeling this one might answer some questions and raise a few new ones.

    Component parameters serve many purposes in Altium Designer®, but really they represent a set of text data about a component. Some of you might have noticed that over time, the Altium Content team has been putting more and more effort into including parametric data within our component content.

    The main reason for this? Search.

    We want to live in a world where designers can search for (and filter results) components based on parameters like; ‘Vs MAX’ or  ‘Control Interface’.


    Right click a component on schematic sheet, and choose ‘find similar component in ’ and get a sensible list of alternatives.

    To make this eventually happen one day, we decided to capture more and more component parametric data.

    I humbly admit, we’ve still quite a way to go ;) both in terms of making the parameters search friendly and making the tools for search itself. But the motives are pretty awesome.

    Standard Parameters

    Firstly, let me get some book keeping out of the way. At Altium we have a handful of a standard parameters we usually include with every component:

    ComponentLinks - These are a set of parameters to link the datasheet, manufacturer and product website addresses.  (Learn more here)

    DatasheetVersion - This is version number /  date code for the datasheet we used to build the component. We prefer to follow the vendor’s versioning system, but dates are format normalized as month-year (eg ‘Mar-2011’).

    PackageDescription - The description of the package (as Altium describes it)

    PackageReference - The vendors name / code for the package.

    PackageVersion - The version number of the datasheet we used to draw the package.

    Mounting Technology - Surface Mount or Through-hole

    Code_JEDEC, Code_IPC - If the package fits a JEDEC or IPC standard, we name it here.

    Part Number and Generic Part Number - The full order code and the component generic code respectively (see my previous post about this).

    RoHS - If the vendor marks a device as compliant to some extent with RoHS we include this parameter. Very often a vendor will mark components as ‘lead-free’ or  ‘RoHS: Yes!’ in which case we standardize this to ‘Pb-Free’. But occasionally the component vendor has their own way to label RoHS (eg ‘eco-friendly’, ‘green’) which might have a slightly different meaning to simply being lead free. In these cases, we use their terminology directly.

    Packing - This would show what kind of packing a component is delivered in (if it is specified by the vendor), for example Tape & Reel, Tray, Bag, etc.

    Normalizing parameters names and values

    All other parameters we take from vendor data, and we take them directly. That is, we (at Altium) do very little parametric normalization.  What do I mean about normalizing parameters ?

    Parametric normalization means using a single set of parameter names, with a single set of units, for the entire set of components .

    Basically, when we looked at component data between different vendors all things were not equal. VIN MAX for one vendor might have a very different meaning as the same parameter from another vendor (for example absolute MAX vs typical MAX, or MAX at certain temperature). and we found very quickly, that we couldn’t effectively normalize this information without making assumptions - some of which were dangerous.

    Therefore it is useful to remember, that when you place a component from the Altium Vault®, the parametric data included might have conditions attached to its value and you should check the datasheet to confirm it means what you think it means.

    Parameter Values

    For normalizing parameter values, we do have a very simple system. Dates and temperature ranges are usually standardized;

    • Dates should use MMM-YYYY format,
    • Temperature Ranges should use -XX to +XX degC

    We also convert most text ‘symbols’ into plain ascii text;

    What do you do for component parameters?

    Personally, I think normalization IS a good idea. But it’s simply not practical for Altium’s own content . I’d love to hear feedback about how / if you all are doing that for components?

    The most obvious way is to define component classes and subclasses and then a set of important parameters for each. Defining the standard parameters could be approached in a few ways;

    • Industry Standard; for example IEC 61360 (have fun: here).
    • Commercially practical; for example the structure used by your favorite online component distributor.
    • Informal: Just make a list of standard parameter names with rough definition of what each one means.

    Very early on we tried each of these, but as mentioned, they were simply impractical for us to implement. But I think for a company wide it would be extremely beneficial.

    Collecting Parameters

    For the Content Development Team, component parameters are extremely important because they very often represent the first major step in a new project. We gather a list of components, links to the datasheet and parametric data from a vendors website and then import it into a spreadsheet;

    Most vendors have a handy download xls / csv button, but we’ve resorted to copy / paste before too.

    It’s from this spreadsheet that we build up our initial list of components complete with the parametric data.

    We do a lot of cleaning up and a little normalizing for our standard parameter set. We also use this as an opportunity to assign symbol, altium package names using the naming conventions outlined in my previous blog (here). Since this is usually teamwork, we use a Google docs spreadsheet and build up the names using formulas, vlookups and perhaps a script.

    I’d happily give Google docs a plug for this kind of work - the scripting and multiplayer mode for spreadsheets is great for pulling together this kind of data quickly and easily.

    For our purpose we call this a ‘scope’, it defines the components we’re going to work on for a project and a starting point for component data. Key phrase here is ‘starting point’, we don’t consider this data to be validated. But from this we begin the more formal component development process.

    I’ll share this example (here, and xls here), which will no doubt spawn some interesting questions ;)

    The nice part about this approach is that it is reasonably simple to take this tabular data and enter it (copy / paste) into a dblib table or .cmplib component .  (explanation of this is in the wiki, here)

    It’s pretty easy to get unique list of packages and symbols from a scope, and set about building those in an organized fashion, ultimately arriving at a completed set of sources for a .

    Next port of call is going to be symbol development and standards.

    Check out Altium in action...

    Powerful PCB Design

    About Author

    About Author

    David Read was appointed General Manager, Altium Greater China in October 2015, and he has worked at Altium since 2001. Originally serving as a Technical Support Consultant for the Australian region from Altium’s office in Hobart, Tasmania, later he moved to the Global Customer Care group at Altium Headquarters in Sydney as an Application Engineer and was later appointed R&D Director in Shanghai Content Center, and from 2013 to 2015, he worked as Product Marketing director. Prior to Joining Altium Mr. Read studied Computer Sciences and worked in the electronics industry.

    most recent articles

    Back to Home