Subcommittee 3D
Download
1 / 19

report for - PowerPoint PPT Presentation


  • 258 Views
  • Updated On :

Subcommittee 3D DATA SETS FOR LIBRARIES. Experience report for implementing IEC 61360 – Conventions and guidelines Cape Town, 2005-10-19 3(Cape Town/Dijkstra)4. Addie Dijkstra Secretary, IEC SC3D. Basic contents. IEC 61360 data dictionary at PSC Need for conventions and guidelines

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' report for ' - RoyLauris


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Slide1 l.jpg

Subcommittee 3D

DATA SETS FOR LIBRARIES


Slide2 l.jpg

Experience report for implementing IEC 61360 –Conventions and guidelinesCape Town, 2005-10-193(Cape Town/Dijkstra)4

Addie Dijkstra

Secretary, IEC SC3D


Basic contents l.jpg
Basic contents

  • IEC 61360 data dictionary at PSC

  • Need for conventions and guidelines

  • Conventions for definition

  • Conventions for naming

  • Conventions for symbol

  • Some questions to you


Iec 61360 data dictionary at psc l.jpg
IEC 61360 data dictionary at PSC

Philips Semiconductors SPIDER program

Type of information to be managed:

Any product information or knowledge

required during any of the stages of the

customer’s product/business creation process

Current status:

Pilot phase – First 700 products defined in the product

library based on data dictionary before end 2005


Goals l.jpg
Goals

  • Capture product parametric information at the source [and only once]

  • Use resulting content to generate:

    • Product information web pages and datasheets

    • Selection guides

    • Electronic data exchange e.g. RosettaNet PIP 2A10


Datasheet l.jpg
Datasheet

Rapidly growing complexity

  • Largest datasheet 1996: 125 pages

  • Largest datasheet 2002: 650 pages with 521 device characteristics!

  • Percentage of web visitors downloading datasheets: 87%

  • Estimated cost to re-create all existing datasheets at current rates: EUR XXX,000,000


  • Dictionary of data element types l.jpg
    Dictionary of data element types

    Dictionary and library information model is based on:

    • RosettaNet Dictionary Architecture model, compliant with ISO/IEC information model (IEC 61360-2)

      Dictionary content:

    • IEC-61360, Philips proprietary and possibly RNTD

      Dictionary will be used as (a.o.)

      a mechanism to enforce standards and consistency


    Need for conventions and guidelines l.jpg
    Need for conventions and guidelines

    Which standards apply

    • Information model

      • IEC 61360-2

    • DET attributes and their definitions

      • ISO/IEC 11179-3, IEC 61360-1

    • Conventions for writing definitions

      • ISO/IEC 11179-4

    • Conventions for writing names

      • ISO/IEC 11179-5 (includes guidelines for writing naming conventions and an example convention)

    • Conventions for writing symbols

      • ISO 31, IEC 60027, 60747, 60748


    Conventions for writing definitions l.jpg
    Conventions for writing definitions

    ISO/IEC 11179-4

    A data definition shall [requirements]:

    • be stated in the singular

    • state what the concept is, not only what it is not

    • be stated as a descriptive phrase or sentence(s)

    • contain only commonly understood abbreviations

    • be expressed without embedding definitions of other data or underlying concepts


    Conventions for writing definitions10 l.jpg
    Conventions for writing definitions

    ISO/IEC 11179-4

    A data definition should [recommendations]:

    • state the essential meaning of the concept

    • be precise and unambiguous

    • be concise

    • be able to stand alone

    • be expressed without embedding rationale, functional usage, or procedural information

    • avoid circular reasoning

    • use the same terminology and consistent logical structure for related definitions

    • be appropriate for the type of metadata item being defined


    Conventions for writing names l.jpg
    Conventions for writing names

    ISO/IEC 11179-5

    Includes guidelines for writing structured naming

    conventions:

    • Semantic rules enable meaning to be conveyed;

    • Syntactic rules relate components in a consistent, specified order;

    • Lexical (word form and vocabulary) rules reduce redundancy and increase precision;


    Naming convention for dets l.jpg
    Naming convention for DETs

    A data element type name shall:

    • be stated in the singular

    • be written in lower case with the exception of particular abbreviations and acronyms that are commonly written in upper case

    • contain only commonly understood abbreviations and acronyms *

      * Managed by a Philips Semiconductors exceptions list for allowed abbreviations and acronyms


    Specific det naming rules l.jpg
    Specific DET naming rules

    Distinguish between type of DET

    • Mechanical quantitative data element types

      • start with the concept or object being specified followed by the measured aspect such as: length, height, diameter

    • Non-quantitative data element types

      • start with the concept or object being specified followed by a qualifier such as: type, code, name, description

    • Electrical quantitative data element types


    Naming convention for dets14 l.jpg
    Naming convention for DETs

    Electrical quantitative data element types

    • reflect the electrical symbol in words reading in reverse order;

    • start with the concept or object being specified, followed by the measured quantity such as: voltage, current, capacitance, temperature;

    • The concept or object is possibly preceded by one or more qualifiers such as: maximum, peak, average, total;

    • The measured quantity is possibly followed by a non-quantitative condition such as: from junction to lead;


    Example l.jpg
    Example

    REMARK –The allowed non-quantitative conditions are managed in a Philips

    Semiconductors non-quantitative conditions list. Only those that are approved

    shall be used.


    Conventions for writing symbols l.jpg
    Conventions for writing symbols

    A symbol shall:

    • use a consistent and approved set of characters;

    • contain only commonly understood abbreviations;

    • use parentheses “()” to separate adjacent symbol parts that are written in the same case (upper or lower);*

    • not exceed a length of 17 characters (not including mark-up);

      * In general, the first part of subscript is not enclosed in parentheses


    Conventions for writing symbols17 l.jpg
    Conventions for writing symbols

    A symbol should:

    • be concise - use the minimum number of letters

    • use consistent logical structure for related symbols

    • reflect the words of the data element type name reading in reverse order

    • derive the first symbol letter from the measured quantity (its basic letter symbol) which relates to the specified unit


    Some questions l.jpg
    Some questions

    Questions:

    • What can TC3 apply from what is already defined in 11179-4 for writing definitions?

    • Could TC3 benefit further from joined conventions on naming and writing symbols?

    • Could IEC benefit from a document such as a guide on Conventions for naming, definition and symbols stating the basic principles?



    ad