USING UML TO UNDERSTAND IEEE 1451'1

1
USING UML TO UNDERSTAND IEEE 1451.1

• Presented by
• Hussein Syed Mohammed
• November 02, 2005, SMART SENSORS

2
OUTLINE

• INTRODUCTION
• UML
• IEEE 1451.1
• UML TUTORIAL ON CLASSES AND OBJECTS
• CLASSES AND OBJECTS IN IEEE 1451.1
• NCAP
• UML TUTORIAL ON STATE MACHINES
• STATE MACHINES IN IEEE 1451.1
• NCAP AND FUNCTION BLOCKS
• CONCLUSION
• QUESTION AND ANSWER SESSION

3
UML INTRODUCTION

• UML
• Unified Modeling Language
• Prior to UML, many conflicting models, methods
  and diagrams
• Created by the 3 Amigos
• Grady Booch
• Jim Rumbaugh
• Ivar Jacobson
• OMG
• Object Management Group
• Open membership, not for profit consortium
• Produces and maintains computer industry
  specifications
• Interoperable enterprise applications

4
UML INTRODUCTION

• WHY DO WE MODEL?
• Models help us to visualize a system as it is or
  as we want it to be
• Models permit us to specify the structure or
  behavior of a system
• Models give us a template that guide us in
  constructing a system
• Models document the decisions we have made
• Allows us to retract and question the decisions
  we have made

The Unified Modeling Language User Guide, Grady
Booch, James Rumbaugh, Ivar Jacobsen
5
UML INTRODUCTION

• EXPECTATIONS OF MODELING
• To give a description of the entire or portion
  of the system from a functional point of view
• To be rigorous
• Does the model have the ability to withstand
  some threshold of time?
• To allow easy translation to modeling software
  or integration with existing functional
  components and entities
• Changes in model should be easily implemented
  without need to reconstruct from scratch

6
UML INTRODUCTION

• CAPABILITIES OF UML
• Provides a formal basis for understanding the
  modeling language
• Provides users with a ready-to-use, expressive
  visual modeling language
• Provides independence of particular programming
  language and development hardware
• Supports object-oriented methods
• Supports higher-level-development concepts such
  as collaboration of framework and components

7
UML INTRODUCTION

• TYPES OF UML DIAGRAMS
• Use Case
• Class
• Object
• Sequence
• Collaboration
• State Chart
• Activity
• Component
• Deployment

DISCLAIMER
The UML is not limited to modeling software. It
is expressive enough to model non-software
systems.
8
IEEE 1451.1 INTRODUCTION

• PROBLEM
• Sensors are interfaced to a variety of
  computers, instruments, and networks via
  different interfaces
• Interoperability problem for system integration
• Additional cost for end users

UML Model for the IEEE 1451.1 Standard, Kang Lee,
Eugene Y. Song
9
IEEE 1451.1 INTRODUCTION

• SOLUTION
• IEEE Instrumentation and Measurement Society
• Initiated an industry lead effort to define IEEE
  1451
• A family of smart transducer interface standards
• Objectives define a set of common communications
  interfaces for connecting transducers to
  microprocessor-based systems, and field networks
  in a wired or wireless, network-independent
  environment
• One of these standards include the IEEE 1451.1

UML Model for the IEEE 1451.1 Standard, Kang Lee,
Eugene Y. Song
10
IEEE 1451.1 INTRODUCTION

• WHAT IS IEEE 1451.1?
• Describes a network-independent information
  model for smart sensors
• Smart transducers, including smart sensors and
  actuators are connected through a Network Capable
  Application Processor (NCAP)
• The standard defines a common object model for
  abstract components of networked smart
  transducers, together with interface
  specifications to these components
• NIST researchers have developed a UML model of
  IEEE 1451.1
• This model is used further research on IEEE
  1451.1

UML Model for the IEEE 1451.1 Standard, Kang Lee,
Eugene Y. Song
11
IEEE 1451.1 EXPLORED

• IEEE 1451.1 ARCHITECTURE EXPLAINED
• The IEEE 1451.1 architecture is defined in 3
  different models
• Object model
• Specifies the software component types used to
  design and implement IEEE 1451.1 based
  application systems
• Defines transducer device specific abstract
  objects (e.g. classes with attributes, methods,
  and state behavior)
• Data model
• User-defined data types (i.e. unsigned, signed)
  for network communication
• Defines information encoding rules for
  transmitting information across both local and
  remote object interfaces

An IEEE 1451.1 Summary, Richard Schneeman
12
IEEE 1451.1 EXPLORED

• IEEE 1451.1 ARCHITECTURE EXPLAINED
• Network communication
• Client-Server
• A tightly coupled, point-to-point model for
  one-to-one communication
• Publish-Suscribe
• A loosely coupled model for one-to-many and
  many-to-many scenarios
• Typically used for broadcasting or multicasting
  measurement data and configuration measurement
  (i.e. NCAP discovery) information
• Supports a client/server and publish/subscribe
  paradigm for communicating information between
  NCAPs

An IEEE 1451.1 Summary, Richard Schneeman
13
IEEE 1451.1 EXPLORED
WHAT ARE THE BENEFITS OF IEEE 1451.1?

• By designing and implementing the different
  objects that are defined in the information model
  that is defined in the standard, we will achieve
  network and transducer independency
• Hide the communication details of the NCAP with
  a particular network and transducers, making the
  applications behavior transparent to the
  physical connections of the NCAP

System-on-a-Chip Solution for Plug and Play
Networked Smart Transducers, Gustavo Eduardo
Lopez
14
IEEE 1451.1 EXPLORED
SOME ISSUES

• In order to implement the information model,
  there are different properties among the NCAPs
  objects that need to be taken into consideration.
  
• These properties include a class hierarchy and an
  owning relationship that can be described using
  Unified Modeling Language (UML)

System-on-a-Chip Solution for Plug and Play
Networked Smart Transducers, Gustavo Eduardo
Lopez
15
BASICS ON UML
SYNTAX
Class

• Top position, centered, bold and capitalized
• List attributes, type and default values
• List operations, along with return type

www.smartdraw.com

• The UML distinguishes between operation and
  method. An operation specifies a service that
  can be requested from any object of the class to
  affect behavior method is an implementation of
  an operation

The Unified Modeling Language User Guide, Grady
Booch, James Rumbaugh, Ivar Jacobsen
16
BASICS ON UML
SYNTAX

• Visibility
• Use visibility markers to signify access to the
  information contained within a class
• Private visibility hides information from
  anything outside the class partition
• Public visibility allows all other classes to
  view the marked information
• Protected visibility allows child classes to
  access information they inherited from a parent
  class

www.smartdraw.com
The concept of visibility is very similar to
information hiding in Object Oriented programming
languages such as C, Java, etc
17
BASICS ON UML
SYNTAX
Generalization

• Another name for inheritance or an "is a"
  relationship
• It refers to a relationship between two or more
  classes where one class is a specialized version
  of another
• Generalization syntax is not limited to just
  class diagrams

Super Class
Sub Class1
Sub Class2
www.smartdraw.com
The concept of generalization is very similar to
inheritance in Object Oriented programming
languages such as C, Java, etc
18
BASICS ON UML
SYNTAX

• Aggregation
• Use a hollow diamond to represent a simple
  aggregation relationship, in which the top"
  class plays a more important role than the
  bottom" class
• Note the two classes need not be dependent on
  each other
• In this example, 1 Object1 owns 0 or more
  Object2s
• In this case, Aggregation is a has-a
  relationship, can be used when an object
  logically or physically contains others objects

WHOLE
Object1
1 Object1 owns 0.. Object2
Object2
PART
www.smartdraw.com
19
IEEE 1451.1 OBJECT MODEL REVISITED

• MORE ON IEEE 1451.1 OBJECT MODEL
• The classes that compose the object model is
  divided into 4 categories
• Block class
• The largest and most significant of the models
  defined in IEEE 1451.1 standards
• IEEE1451_NCAPBlock, BaseTransducerBlock,
  FunctionBlock
• BaseTransducerBlock and FunctionBlock are
  abstract classes
• Component class
• Services class
• Non-IEEE 1451.1 object class
• Provide an implementation of application systems
  specific actions and services

Formal Specifications of IEEE 1451.1 Fragments,
Ondrej Rysavy, Frantisek Bures
20
IEEE 1451.1 MEETS UML

• ATTRIBUTES EXPLAINED
• class_ID
• Identifies the objects class position in the
  class hierarchy
• object_ID
• Unique within a system and unambiguously
  distinguishes the object from the other objects

21
IEEE 1451.1 MEETS UML
IEEE1451 NCAPBlock CLASS DIAGRAM

System-on-a-Chip Solution for Plug and Play
Networked Smart Transducers, Gustavo Eduardo
Lopez
22
IEEE 1451.1 MEETS UML
IEEE1451 FUNCTIONBlock CLASS DIAGRAM
Italic Abstract
System-on-a-Chip Solution for Plug and Play
Networked Smart Transducers, Gustavo Eduardo
Lopez

• Root for the class mechanism for the abstraction
  and hierarchy of all Function Block Objects
• Interaction between the application objects and
  other standard-defined objects will be done
  through this class

IEEE Standard for a Smart Transducer Interface
for Sensors and Actuators - Network Capable
Application Processor (NCAP) Information Model
23
IEEE 1451.1 MEETS UML
IEEE1451 TRANSDUCERBlock CLASS DIAGRAM
Italic Abstract
System-on-a-Chip Solution for Plug and Play
Networked Smart Transducers, Gustavo Eduardo
Lopez
24
IEEE 1451.1 CONCEPTS
CONCEPTUAL VIEW
Communications Interface
Transducer Block
Network Port
Transducer Interface
Parameters, Actions, Files and other Objects
NCAP Block
An IEEE 1451.1 Summary, Richard Schneeman
25
IEEE 1451.1 CONCEPTS
IEEE1451_NCAPBlock Centralizes and glues
network and communications systems Transducer
Block Maps the physical transducer to the NCAP
CONCEPTUAL VIEW (continued)
An IEEE 1451.1 Summary, Richard Schneeman
26
IEEE 1451.1 CONCEPTS
Function Block Application code is plugged
in as needed
CONCEPTUAL VIEW (continued)

• Parameter Objects
• Provides means of modeling network visible
  objects and a means for accessing them
• Action Objects
• Physical activities taking place over an extended
  time period
• File Objects
• Provide network-accessible data and code storage
• Port Objects
• Network communication

27
IEEE 1451.1 MEETS UML
IEEE1451_Entity ltltAbstract Classgtgt
IEEE1451_Block ltltAbstract Classgtgt
IEEE1451_Component ltltAbstract Classgtgt
IEEE1451_Service ltltAbstract Classgtgt
28
IEEE 1451.1 MEETS UML

• PURPOSE OF BLOCKS
• Provide standard software interfaces for
  supporting of network communications and system
  configuration, and encapsulate application
  functionality
• MORE ON IEEE 1451.1 OBJECT MODEL
• The IEEE1451_Block is the superclass (parent
  class) of the NCAPBlock, FunctionBlock and
  BaseTransducerBlock
• The NCAPBlock (child class/subclass) can inherit
  the attributes and operations (functions) from
  the IEEE1451_Block

29
IEEE 1451.1 MEETS UML
INHERITANCE AGGREGATION RELATIONSHIP OF IEEE
1451.1 OBJECTS
UML Model for the IEEE 1451.1 Standard, Kang Lee,
Eugene Y. Song
30
IEEE 1451.1 MEETS UML

• MORE ON OWNERSHIPS
• 2 LEVELS OF OWNERSHIP
• Ownership relationship among block objects
• Ownership relationship between block objects and
  other objects (i.e. components and transducer
  blocks)

31
IEEE 1451.1 MEETS UML

• MORE ON OWNERSHIPS
• IEEE1451_NCAPBlock
• Top-level block in the process space
• Only object that owns itself
• Can own other objects, IEEE1451_FunctionBlock,Ba
  seTransducerBlock
• IN GENERAL
• One IEEE1451_NCAPBlock, FunctionBlock,
  BaseTransducerBlock can own or consist of zero
  or more Components and zero or more Service
  objects respectively
• Only Blocks can own other objects

32
IEEE 1451.1 MEETS UML

• MORE ON IEEE1451_NCAPBlock
• Provides resources and operations within an NCAP
  process to support Block, Service and Component
  management
• This includes the following
• Object registration
• Initialization
• Start Up
• Shut Down

IEEE Standard for a Smart Transducer Interface
for Sensors and Actuators - Network Capable
Application Processor (NCAP) Information Model
33
IEEE 1451.1 MEETS UML
MORE ON IEEE_1451NCAPBlock

• 3 Different Layers
• Network Abstraction
• Application
• Transducer Abstraction

1
2
3
System-on-a-Chip Solution for Plug and Play
Networked Smart Transducers, Gustavo Eduardo
Lopez
34
IEEE 1451.1 MEETS UML

• MORE ON IEEE_1451NCAPBlock
• NETWORK ABSTRACTION LAYER
• Hardware shall consist of the network-specific
  logic that is needed for the underlying network
• Software for this layer shall consist of the
  network library (network-specific), and the
  1451.1 API (standard-defined)

System-on-a-Chip Solution for Plug and Play
Networked Smart Transducers, Gustavo Eduardo
Lopez
NETWORK ABSTRACTION LAYER
35
IEEE 1451.1 MEETS UML

• MORE ON IEEE_1451NCAPBlock
• NETWORK ABSTRACTION LAYER (continued)
• Network Library
• Responsible for encoding and decoding data
  to/from on the underlying network
• 1451.1 AP1
• Provide the network independency of the design
• Hides the communication details of the network
  driver

System-on-a-Chip Solution for Plug and Play
Networked Smart Transducers, Gustavo Eduardo
Lopez
36
IEEE 1451.1 MEETS UML

• MORE ON IEEE_1451NCAPBlock
• APPLICATION LAYER
• Consist only of software blocks
• Standard-defined blocks for application
• Application specific code
• Act as a bridge between Network operations and
  Transducer operations

System-on-a-Chip Solution for Plug and Play
Networked Smart Transducers, Gustavo Eduardo
Lopez
APPLICATION LAYER
37
IEEE 1451.1 MEETS UML

• MORE ON IEEE_1451NCAPBlock
• TRANSDUCER ABSTRACTION LAYER
• Specific hardware to communicate with the TIM
• Responsible for physical connection between NCAP
  and TIM
• Software shall consist of Transducer I/O API

System-on-a-Chip Solution for Plug and Play
Networked Smart Transducers, Gustavo Eduardo
Lopez
TRANSDUCER ABSTRACTION LAYER
38
IEEE 1451.1 MEETS UML

• NETWORK VISIBLE OBJECTS
• Can be accessed and their operations can be
  invoked from a different process than the process
  in which the operations of objects are executed
• It does not matter whether the different process
  is running in the same NCAP or in a different
  NCAP and communicating over a network
• An object is network visible if it conforms to 3
  rules
• Only instances of subclasses should be made
  network visible objects
• Need for registration of object in local NCAP
  block object
• Requires the object being owned by the local
  NCAP Block

39
IEEE 1451.1 MEETS UML
MORE ON IEEE1451_NCAPBlock

• MORE ON IEEE1451_NCAPBlock
• REGISTERING AND DEREGISTERING OBJECTS
• What does that do?
• To become network visible, an object must be
  registered with its local NCAPBlock
• To register, the RegisterObject operation should
  be used
• If the object is not registered, they cannot be
  accessed directly by the network
• To deregister, the DeregisterObject operation
  should be used

System-on-a-Chip Solution for Plug and Play
Networked Smart Transducers, Gustavo Eduardo
Lopez
40
IEEE 1451.1 MEETS UML

• PURPOSE OF IEEE1451_NCAPBlock (SUMMARY)
• Keeps information on device configuration within
  the scope of a single process
• Key source of system configuration and
  bookkeeping information about its Network Visible
  Owned Objects

41
BASICS ON UML (continued)
TERMS AND CONCEPTS A state machine is a behavior
that specifies the sequences of states an object
goes through during its lifetime in response to
events A state is a condition or situation
during the life of an object which it satisfies
some condition, performs some activity, or waits
for some event An event is the specification of
a significant occurrence that has location in
time and space
The Unified Modeling Language User Guide, Grady
Booch, James Rumbaugh, Ivar Jacobsen
42
BASICS ON UML (continued)
TERMS AND CONCEPTS A transition is a relationship
between two state indicating that an object in
the first state will perform certain actions, and
enter the second state when a specified event
occurs and specified conditions are satisfied An
activity is an ongoing execution within a state
machine An action is an executable computation
that results in a change in state of the model or
return of a value
The Unified Modeling Language User Guide, Grady
Booch, James Rumbaugh, Ivar Jacobsen
43
BASICS ON UML (continued)
SYNTAX
States

• States represent situations during the life of
  an object
• Note that it looks like a rectangle with rounded
  corners

www.smartdraw.com
Example of States
Names
States
44
BASICS ON UML (continued)
SYNTAX
Initial State

• A filled circle followed by an arrow represents
  the object's initial state

Terminal State

• An arrow pointing to a filled circle nested
  inside another circle represents the final action
  state

www.smartdraw.com
45
BASICS ON UML (continued)
SYNTAX
Arrow

• An arrow represents the path between different
  states of an object
• Label the transition with the event or condition
  that triggered it and the action that results
  from it

www.smartdraw.com
Example of Arrow Usage
46
IEEE 1451.1 MEETS UML (continued)

• MORE ON IEEE 1451.1 NCAPBlock CLASS
• The NCAPBlock class has three states
• BL_INACTIVE (Sequential composite substate)
• A state that contains one or more disjoint
  substates, exactly one of which is active when
  the composite state is active
• Decomposed further into 2 states
• NB_INITIALIZED
• NB_ERROR
• BL_ACTIVE
• BL_UNINITIALIZED

47
IEEE 1451.1 MEETS UML (continued)

• BL_UNINITIALIZED STATE
• Reserved for local activities related to
  bringing the Block Object into existence
• Perform any related local preparations needed
  for the Block Function
• While in this state, any classes owned by the
  Block class cannot execute any network
  communications
• However, it is in this state that the owned
  objects are registered with the Block for network
  communications

System-on-a-Chip Solution for Plug and Play
Networked Smart Transducers, Gustavo Eduardo
Lopez
48
IEEE 1451.1 MEETS UML (continued)

• BL_INACTIVE STATE
• Reserved for activities such as configuration of
  the network communication properties of the Block
  and its owned objects
• Initialization, that is bringing the Block
  Object and its Owned objects into a known state
  in preparation for the transition into the
  BL_ACTIVE state
• Diagnosis and maintenance of the Block object

• BL_ACTIVE STATE
• Reserved for activities related to the normal
  application function of the block

IEEE Standard for a Smart Transducer Interface
for Sensors and Actuators - Network Capable
Application Processor (NCAP) Information Model
49
IEEE 1451.1 MEETS UML (continued)
STATE MACHINE FOR NCAPBlock (INCOMPLETE)
50
IEEE 1451.1 MEETS UML (continued)
STATE MACHINE FOR NCAPBlock (COMPLETE)
PSK PSK_NCAPBLOCK_GOACTIVE
RESET
BL_ACTIVE
REGISTER OBJECT
GOINACTIVE
GOACTIVE
POWER DOWN
BL_INACTIVE
BL_UNINITIALIZED
INITIALIZE
INITIALIZE
DEREGISTER OBJECT
DEREGISTER OBJECT
POWER DOWN
POWER DOWN
RESET
51
IEEE 1451.1 MEETS UML (continued)
ORIGINAL STATE DIAGRAM
UML Model for the IEEE 1451.1 Standard, Kang Lee,
Eugene Y. Song
52
IEEE 1451.1 MEETS UML (continued)

• BLOCK COOKIE
• The value of a cookie of a specific block
• Quantity used to indicate or signal to a
  recipient of data, significant changes in the
  state of the entity supplying the data
• All Network Visible Block Objects, and Block
  Objects (in particular) have a Block Cookie

IEEE Standard for a Smart Transducer Interface
for Sensors and Actuators - Network Capable
Application Processor (NCAP) Information Model
53
IEEE 1451.1 MEETS UML (continued)
STATE MACHINE FOR FUNCTIONBlock (INCOMPLETE)

54
IEEE 1451.1 MEETS UML (continued)
STATE MACHINE FOR FUNCTIONBlock
55
IEEE 1451.1 MEETS UML (continued)
PSEUDO-CODE FOR FUNCTIONBlock
START()
System-on-a-Chip Solution for Plug and Play
Networked Smart Transducers, Gustavo Eduardo
Lopez
56
IEEE 1451.1 MEETS UML (continued)
PSEUDO-CODE FOR FUNCTIONBlock
PAUSE()
System-on-a-Chip Solution for Plug and Play
Networked Smart Transducers, Gustavo Eduardo
Lopez
57
IEEE 1451.1 MEETS UML (continued)
STATE MACHINE FOR FUNCTIONBlock (COMPLETE)
58
IEEE 1451.1 SUMMARY

• BENEFITS OF IEEE 1451.1
• An extensible object-oriented model for smart
  transducer application development and deployment
• Application portability achieved through agreed
  upon application programming interfaces (API)
• Network neutral interface allows the same
  application to be plug-and-play across multiple
  network technologies
• Common software interface to transducer hardware
  I/O

An IEEE 1451.1 Summary, Richard Schneeman
59
IEEE 1451.1 SUMMARY

• MORE ON IEEE1451_NCAPBlock
• NETWORK VISIBILITY
• An IEEE1451_NCAPBlock is implicitly defined as
  Network Visible, because an application system
  accesses firstly the NCAP block object of an NCAP
  component after the NCAP component is created
• All other objects created in the NCAP component
  are made Network Visible, just by their
  registration in their local NCAP block object

Formal Specifications of IEEE 1451.1 Fragments,
Ondrej Rysavy, Frantisek Bures
60
CONCLUSIONS

• WHAT WE HAVE COVERED
• UML
• INTRODUCTION
• SOME BASIC UML
• IEEE 1451.1
• INTRODUCTION
• APPLICATION OF UML IN IEEE 1451.1
• SUMMARY

61
SOME CONCLUDING COMMENTS ON UML
FOR THE UML ENTHUSIAST
UML www.uml.org TUTORIALS
www.smartdraw.com www.uml-forum.com/tutorials.
htm www.visualcase.com/tutorials/uml-tutorial.h
tm SOFTWARE www.gentleware.com
www.visual-paradigm.com/
62
REFERENCES
UML Model for the IEEE 1451.1 Standard, Kang Lee,
Eugene Y. Song
Formal Specifications of IEEE 1451.1 Fragments,
Ondrej Rysavy, Frantisek Bures
The Unified Modeling Language User Guide, Grady
Booch, James Rumbaugh, Ivar Jacobsen
IEEE Standard for a Smart Transducer Interface
for Sensors and Actuators - Network Capable
Application Processor (NCAP) Information Model
An IEEE 1451.1 Summary, Richard Schneeman
System-on-a-Chip Solution for Plug and Play
Networked Smart Transducers, Gustavo Eduardo
Lopez
www.smartdraw.com
www.uml.org
63
HOMEWORK

• IEEE 1451.1 AND UML
• Please submit the following homework to Dr
  Schmalzel to show that you have attained some
  level of understanding of the concepts and points
  raised in todays lecture.
• Write pseudo-code for the Function Block for the
  Resume() and Clear() operations in the manner
  shown earlier.
• Draw the state diagram of the IEEE1451_TransducerB
  lock. This is again, very similar to the state
  diagrams seen earlier with a slight modification.
  Explain briefly what is the result of this
  modification. You can easily get material from
  the ISHM page

IEEE Standard for a Smart Transducer Interface
for Sensors and Actuators - Network Capable
Application Processor (NCAP) Information Model
64
QUESTIONS
Thank you