PICON SENSOR DESCRIPTION

BASIC SENSOR -------------------------------------------------------------------

ATTRIBUTES FRAME FIELDS:
    Tagname
    System I.D.
    Routing Code
    Associated unit
    Currency interval
    Smoothing factor
    Problem Action

FIELDS DEFINITION:
    Tagname ----
        Alphanumeric [A-Z 0-9] name of this sensor used by all rules.  This
        field is always supplied to RTIME and RTIME will always respond to
        problems with this sensor by this tagname.  Force upper case for a-z,
        and use caseless match in rules.
    
    System I.D. ----
        Single character alphanumeric [A-Z 0-9] used primarily by RTIME to
        identify which distributed system to associate this node with in
        multiple distributed system networks.  There are cases when PICON should
        use this fields information:  network failure of a single network in
        multiple system - RTIME will notify all nodes this system not available,
        duplicate tagnames on two networks - in the rules PICON will have to
        check and ask which network.

    Routing Code ----
        Alphanumeric [all printable ASCII characters] string whoes basic
        function is to discribe a network address when the distributed system
        does not support tagnames (Honeywelland Reliance both use a code made
        up of box number, rack number, card number, and loop number in hex).
        A second use of this field is made by RTIME in some systems.  In
        systems, such as British Petrolems, the format of the data for each
        sensor must be known by the requestor as there is no network indication
        as to byte, short, integer, or float format.  By allowing special
        characters [!@#$%^ (for example)], a format character can be imbeded in
        the route code.

    Associated unit ----
        Alpha string used by PICON to performe "focus" operations.
    
    Currency interval ----
        The time period for which this sensor reading can be assumed valid.
        PICON keeps track of how often any rule access the data from a sensor
        and if RTIME supplies the data automatically four (4) times without
        a rule needing the data, RTIME is instructed to no longer get the data
        in automatic mode but rather get data in oneshot mode (i. e. on demand
        from PICON.  This algorthm can be overrriden in two ways:  the sensor
        can be set to ask RTIME for a fresh reading for each data request,  and
        PICON can be instructed to let RTIME gather data all the time for
        historical purposes.  Note:  Most distributed system networks are data
        transfer limited and therefore the continous gathering of data should
        be a manual override.

    Smoothing factor ----
        Some instrumentation is very noisy and needs a filter on its values.
        The common filter formula is:
            new_base = old_base * ( 1-n) + n * current_reading.
            where n is the smoothing factor value
        For some unknown reason this smoothing is done in PICON rather than
        RTIME.
    
    Sensor problem ----     (may be wrong name label)
        There are two implementations for this field: blank and a rule.
        Blank implementation --- no rule inserted.
            When RTIME detects a data problem with a sensor it supplies PICON
            with a string thru the status channel (ttyl4).  The format of
            this string is:
                byte   --- SOH   BINARY 1
				byte   ___ CODE  -  major catagory of error
						   o = reserved
						   1 = offline
						   2 = bad value
						   3 = undefined sensor
						   4 = no response
						   5 thru 255 not yet defined
                byte   --- number of fields this message
                byte   --- sub-message 1 length
				bytes  --- ASCII tagname
                byte   --- sub-message 2 length
                bytes  --- binary data from data supplier indicating problem
						   in HEX ASCII
                byte   --- sub-message 3 length
                bytes  --- verbage from a table supplied by customer that
                           describes the error based on the binary data.
        Rule implementation ---
            PICON rules can be inserted in the field.  Normally a "focus" or
            "conclude" type of rule is used.

   ttyl4  status   one sensor
   ttyl6  alerts   user specified condition detected
   ttyl7  faults   process system not reporting

End sensor 101. Sensor 102 to follows.