A Universal Smart Transducer Interface - PowerPoint PPT Presentation

ostinmannual
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
A Universal Smart Transducer Interface PowerPoint Presentation
Download Presentation
A Universal Smart Transducer Interface

play fullscreen
1 / 47
Download Presentation
A Universal Smart Transducer Interface
760 Views
Download Presentation

A Universal Smart Transducer Interface

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. A Universal Smart Transducer Interface Hermann KopetzNovember 2001

  2. Outline • Introduction • Requirements • The Interface File System • The CORBA Interface • The UART Protocol • Conclusion

  3. Smart Transducer • A smart transducer comprises the integration of one or more MEMS sensor/actuator elements with a microcontroller that provides the following services across standard interfaces: • signal conditioning • calibration and conversion to standard units • diagnostic and maintenance • real-time communication • The idiosyncrasies of the smart sensor/actuator can be hidden behind a standard interface. • In the future, smart transducers will be manufactured in mixed signal technology on a single die.

  4. Advantages of Smart Sensor Technology • No noise pickup from long external signal transmission lines. • Better Diagnostics--Simple external sensor failure modes (e.g., fail-silent, i.e., the sensor operates correctly or does not operate at all). • "Plug-and-play" capability if the sensor contains its own documentation on silicon. • Reduction of the complexity at the system hardware and software and the internal sensor failure modes can be hidden from the user by a well-designed fully specified smart sensor interface. • Cost reduction in installation and maintenance.

  5. Requirement: Small Jitter Control Model Sensor Processing Actuator Control Object (Vehicle) We must know the exact time difference between observing and acting

  6. Requirement: Composability • We call an architecture composable with respect to a specified property, if the system integration will not invalidate this property provided it has been established at the subsystem level, e.g.: • Timeliness • Testability • System properties should follow from subsystem properties. • Otherwise the system integrator is left with the challenging task to find out why the system does not work, although all subsystems work according to their specifications.

  7. Composability • Compose: “to make or form by combining things, parts, or elements” • Composition: “the act of combining parts or elements to form a whole” Webster Encyclopedic Dictionary, 1989, p. 302 • Composability: “The ease of forming a whole by combining parts” • Parts: The component systems • Whole: A system of systems (SOS). • A composition brings into existence new emerging services of the SOS that are more than the sum of the prior services of the components. • These emerging services are the result of the integration of the component systems.

  8. How is the “Integration” achieved? • The component systems are integrated by the exchange of messages across the real-time service interfaces. • Our focus is on what are the contents of a message (data) and when a message is sent and received (time). • We abstract from the low-level (physical, coding) aspects of communication. • We assume that all property mismatches of the interacting systems have been resolved by a connection system.

  9. The Four Principles of Composability • Independent Development of the Components (Architecture)The message interfaces of the components must be precisely specified in the value domain and in the temporal domain in order that the component systems can be developed in isolation. • Stability of Prior Services (Component Implementation)The prior services of the components must be maintained after the integration and should not fail if a partner fails. • Performability of the Communication System (Comm. System)The communication system transporting the messages must meet the given temporal requirements under all specified operating conditions. • Replica Determinism (Architecture)Replica Determinism is required for the transparent implementation of fault tolerance

  10. Requirement: Short Error Detection Latency • There should be a short error detection latency for the detection of • Message corruption • Transducer failure. This is of particular importance in systems with a safe state--example power window--safe state is stop. • Fundamental limitations of asynchronous systems -- if I don’t hear anything, I don’t know whether nothing has happened or the system has failed.

  11. Requirement: On-chip Oscillator • In the future, low-cost micro-controllers will have on-chip oscillators that are very imprecise (+- 50% of nominal frequency) and have a low long-term stability (+- 10% drift/second). • Without start-up calibration of these oscillators and continuous resynchronisation, serial communication is nearly impossible. • Consequences: • Field-bus needs a master with a stable time-base. • Communication protocol must provide facilities for start-up synchronisation and resynchronisation.

  12. Requirement: LOW LOW Cost • An ST-interface standard will only succeed if it can be implemented with minimal resource requirements at low cost: • Mass market applications are very cost sensitive • Mixed signal chips have a larger feature size than pure logic chips • On-chip oscillator reduces sensor costs significantly • 8-bit micro-controllers dominate smart sensor market

  13. What is a Real-Time (RT) Interface? • An RT-interface is a common boundary between subsystems that allows the timely exchange of observations between these subsystems. • An observation is a triple • <Name of an RT-entity, time of observation, value of observation>. • Communication across an RT interface is only possible, if the participating subsystems share a common set of concepts concerning • Common notion of time and its representation • Meaning of the names of RT entities • Shared code-space for the representation of values • Access protocol to the information. • A universal smart transducer interfaces must specify thiscommon knowledge.

  14. A Sensor Produces Observations How long is the RT image, based on the observation: “The traffic light is green” temporally accurate ? RT entity RT image in the car Observation: <Name of RT entity, instant of observation, value>

  15. State versus Event Observations

  16. State Message versus Event Message • Periodic State Message: A message that contains only state observations (synchronous).Message handling: update in place and non-consuming read.Periodic state messages can be implemented as an elementary interface (nodependence of sender on receivers) with error detection at the receiver. • Event Message: A message that contains only event observations (asynchronous).Message handling: exactly-once semantics, realized by message queues. Requires a composite interface (dependence of sender on receivers) for error detection at the sender.

  17. Conceptual Model of an ST All nodes have access to a global time of known precision. • Temporal AccuracyRelationship • State Messages Smart Transducer CORBA Gateway RT Imageof SD Sensor Data(SD) Real Time Transport Service Known Delay Minimal Jitter Different RT Transport Protocols supported

  18. The Three Interfaces of a Smart Transducer Node • Real-Time (RS) Service Interface-TT: • Contains RT observations • Time sensitive • In control applications periodic • Diagnostic and Maintenance (DM) Interface-ET • Sporadic Access • Requires knowledge about internals of a node • Not time sensitive • Configuration Planning (CP) Interface-ET: • Used to install a COTS node into a new configuration • Not time sensitive • The ST Submission supports all three of these interfaces.

  19. The Three Interfaces of a Smart Transducer Configuration Planning Interface Local Interfaces to Sensor/Actuator LIF Service Interface Relevant for Composability Diagnostic and Management Interface (Boundary Scan in Hardware Design)

  20. Interface File System CP Interface Interface File System Application Specific Sensor Functions Sensor Element Read Write Read Write RS LIF Interface DM Interface The Interface File System (ISF) encapsulates all information that is exchanged between a smart transducer and its environment. It provides a standardized structured name-space for information access

  21. Structure of a Large ST System--Logical Name: CORBA Gateway Logical Name is concatenation of: Cluster Name Node Name File Name Record Name Total: 4 bytes Cluster B Cluster C Cluster A Transducer Node

  22. Physical Name of a ST • Every ST has a unique physical name (8 bytes) consisting of a • node type name (series number) • node name within series (serial number) • During operation a node is addressed by a one-byte logical name--unique within each cluster. • The assignment of a logical name to a node is called baptizing and can be performed on-line. • Low cost nodes can have preprogrammed logical names

  23. Flow Control in Unidirectional Data Transfer • Information push • Information pull • Time-triggered Sender Control Receiver Data Sender Receiver Sender Receiver

  24. Control Flow and Data Flow in ST Interface Sensor IFS Memory Gateway(CORBA)Memory ORB Information Push Ideal for Sender Time-Triggered CommunicationSystem Information Pull Ideal for Receiver

  25. Principle of Operation of ST Interface • Endpoint of the communication is a named record in the Interface File System (IFS) located in the transducer node. • Communication is organised into rounds • A round is started by the active master that has knowledge of the global time • The first frame of a round is a fireworks frame, followed by data frames. The structure of a round is described in the round-descriptor list (RODL). • every round is independent of every other round • The arrival of the fireworks frame is the global synchronisation event starting a new epoch.

  26. Interface File System (i) Interface File System Internal Logic of Sensor is Encapsulated Write by Client Read Sensor Element

  27. Interface File System (ii) • Provides the structured name space for the RT images and other node-relevant data (e.g., documentation). • Consists of a set of index-sequential files with constant record length and longitudinal and vertical parity. • The following file operation are supported • read record • write record • execute file (e.g., a JAVA applet) • The round-descriptor list (RODL) is stored in the file system as a distributed file of the TTP/A cluster.

  28. Interface File System is Distributed • Optimized for 8-bit sensor architecture and 32 bit gateway architecture: • 250 Clusters • 250 nodes in each cluster • 64 files in each node • 256 records in each file (a record contains 4 bytes) • Total in the order of 230 records in IFS • 3 operations on records: read, write, execute

  29. Interface File System Contains • Node identification (physical name, logical name) • Documentation and pointer to register service • Sensor and actuator data • Configuration Information (Round Descriptor List RODL and Round Sequence File ROSE) • Calibration data, parameters, etc.

  30. TTA and the CORBA Architecture TTA IFS Corba Facilities:Time Internationalization Domain Specific, e.g, Banking Health Care TTA CNI Object A Object B ORB at A ORB at B Object Request Broker (ORB)--GIOP communication Corba Services: Naming Transaction Security Persistent State Event Notification, and more

  31. Representation of an Observation at the ORB • An observation is a triple • <Name of an RT-entity, time of observation, value of observation> • 4 byte name field (cluster, node, file, record) • 8 byte time field (external time) • 4 byte value field (or more if required by application) • 4 byte attribute field (confidence marker, precision indicator, error flags, etc.)

  32. Register Service • Establishment of a link to the meta-data about an ST node(node type is the key to the node documentation on the net) • Namespace management to assign unique physical names to the STs • Maintain ST yellow pages

  33. RT Communication: Round Types • Multi-partner Round: • used for periodic the time-triggered RS Service, reading and writing data of the IFS records containing RT images. • Master-Slave Round: Round name Data Data Data Data Time Record Address Record Data Time used for the event-triggered MD and CP service that read andwrite records of the IFS containing calibration, diagnostic and configuration data..

  34. Interleaving of Rounds • Master Slave Rounds have constant frame length. • Master Slave Rounds may be empty, if no CM or CP service is requested by the master. Recommended Schedule: Multipartner Round Master/SlaveRound Multipartner Round Master/SlaveRound Multipartner Round Real Time

  35. Fireworks • A fireworks sent by the active master starts a new round. • In case of a multi-partner (MP) round, the fireworks frame contains a write command and the name of the selected RODL file. • In case of a master slave (MS) round, the firework frame contains the read/write command and the address of the selected record (node name,file name, record name) • The receipt of the fireworks frame is a global synchronisation event starting a new epoch. • The fireworks frame has characteristic features in the value domain and time domain.

  36. External (CORBA) Time Format Time horizon Time granularitydetermined byprecision of GPS Elapsed seconds since January 6, 1980 at 00:00(GPS base) 1 sec 2-24 sec 240 seconds external time format (8 bytes) Start of epoch: January 6, 1980 at 0:00:00 UTC Granularity about 60 nanosecond

  37. Internal (Smart Transducer) Time Format Slots since FW of MS round • Start of epoch: Falling edge of Fireworks Byte of MS round • Granularity: One slot (13 bit-cells) in short format (1 byte) • Finer granularity application specific • Horizon: 256 Slots • Epoch Counter in MS round: 256 epochs Epoch

  38. Confidence Marker • The sender assigns a four bit confidence marker to the delivered value: • 1111 high confidence 0000 no confidence • Confidence marker are manipulated if replicated sensors are available. For example, if two sensors deliver the same value with a confidence marker of 0100, the result may have the same value with a higher confidence, e.g., 0110. • Confidence markers must be transmitted out of band!

  39. UART Implementation of TTP/A Framing Bit Significant delay beforeparameter byte First Data Byte sent by master Parity Bit Real Time UART Slot:1 start bit 8 data bits 1 parity bit 1 stop bit 2 interframe bits 13 bits total slot length: Fireworks Frame

  40. Data Security • Fireworks byte has a Hamming distance of at least 4 • Every byte contains a parity bit • Every frame of an MS round is protected by check byte • MP round frames can be protected by four bit or eight bit checksum • IFS files can be protected by record checksum and file checksum (allows single bit error correction) • Standardized error codes • Confidence marker to express confidence in sensor reading

  41. Start-up Synchronization of Low-Cost Nodes • Fireworks byte of MSA round has following pattern (0x55) Used for start-up synchronization of chips with on-chip oscillator Many of these chips will have a software UART

  42. Physical Layer • For the low speed UART implementation, the following physical layer is recommended: • ISO 9141 (in conformance with SAE J1978 ad SAE J1850) • transmission speed: 10 kbits/s on single wire • For higher speeds, other physical layers can be used (e.g., CAN physical layer).

  43. Implementation Experience • The slave part of the ST protocol has been implemented on different micro controllers (Motorola MC68376, Atmel AT90S2313): • UART in software • Protocol size, including IFS about 1000 bytes • 1.2 msec per byte at 10 kbits/seconds • The master part that provides access to the ST system via the standard TTP CNI was implemented on a TTP node on the Motorola 98376 microprocessor.

  44. Pick your Set of ST Services Plug and Play On chip Os. Ext. Time Serv. Sleep Clock Sync MS RoundorMP Round MS Round MP Round Baptizing Multi Rec Obs.

  45. Outlook: Replicated ST Busses Backbone Bus to other clusters Gateway Real-TimeBus (TTP/C) fault-tolerant Master Master Slaves (Sensor, Actuator) TTP/A TTP/A

  46. Outlook: Dynamic Development • Development system for the on-line extension and modification of ST subsystems: • Detect new nodes • Baptize new nodes • Access a register service to find node documentation • Develop node software • Download node software • |Switch schedules • . . . And all of this while the RT system is performing its RT service without interruptions.

  47. Conclusion • Universal Smart Transducer Interface • Composability and Testability • Standard Interface File System (IFS) • Jitter Guarantee for Control Applications • Good Error Detection for fail safe operations • Low Cost for intelligent sensors, smallest implementation less than 2 kbytes of ROM, 64 bytes of RAM (including IFS, software UART at 10 kbits on single wire) • Fault tolerance at system level (duplicated buses)