Introduction to UML

Booch’s definition of UML is a graphical language for visualizing, constructing, and documenting the artifacts of a software intensive system . It is a language that captures the object-oriented model. Some of the items this model stresses are data encapsulation, information hiding, and inheritance. UML has mainly been targeted for software projects where it has met the most success. UML’s intent is to capture the object-oriented (OO) model, and many OO practitioners have praised this model. We
also hope to reap some of the OO benefits, and believe we are not limited by the software nature of UML. We believe in philosophy that software and hardware can be abstracted away so we do not see UML’s software nature as a big hindrance. We also hope to use object-oriented properties to ultimately promote reuse. Actually there already exists an object-oriented language for protocols called SDL. SDL is more formal with its communication, assumptions, and it is a Formal Description Technique (FDT). SDL is based on an extended finite state machines (EFSM) framework that have asynchronous processes with zero-delay intra-process signals  and unbounded delay between process blocks. We see UML not as a replacement for SDL but as a front-end for it. SDL was not at the right level of abstraction to begin designing protocols so we had hoped UML could remedy this. UML is really very general (and
still incomplete) but this gives us freedom to explore structures without worrying too much about the details.
Thus the main focus of this paper is the exploration of next generation protocol structure, but first let us finish describing the semantics of UML UML is still under development and is mainly a notation rather than a formal language right now. UML does not clearly define the communication between objects very rigidly. It uses the notion of message passing, but they can be rendezvous or unsynchronized or different shades of both. Also the existence of queue is implied but the exact type is not specified. Each object in a UML diagram has a class which generalizes that object, and within the class there is a state diagram that describes the behavior. These state diagrams are very much like Harel’s STATEMATE for statecharts [HN96]. UML allows states to be hierarchical, concurrent, and nondeterministic defined by {name, entry/exit actions, internal transition, substates, deferred events}. State transitions are defined
by {source state, event trigger, guard condition (on event trigger), action (atomic, local object only), target state}. States are reactive, but not synchronous and process that occur on transitions or in states have some unknown bounded delay. Actually UML carries no notion of any time, real or abstract. All this expressive power tends to causes trouble in completely specifying a system for the real-time systems.
Its practitioners have recognized these problems and have added some constraints to synthesize usable code. These constraints include fully deterministic state machines and some partial ordering of signals . However, it is not our intent to construct some underlying MoC for UML. We use UML as tool to visualize object-oriented protocol structures, and in this aspect we found it useful. The message sequence charts helped to describe dynamic behavior, state charts helped describe some internal behavior, class diagrams helped describe the structure.

Source: Internet


Embedded Communication-Introduction

Communication is essential to achieving a dependable distributed embedded system. Designers of these systems are faced with several challenges in specifying the communication network. Complex systems usually require some sort of shared media network. In this environment, the designer must recognize the fundamental trade-off that exists between the efficiency and the predictability of the network. Given this trade-off, the designer must evaluate and select the communication network. Particular attention must be given to the protocols, which determine much of the network behavior. Finally, many error detection methods are available which are necessary to build a reliable communication system.

Most historical communication systems can be considered to be “embedded” at least from one perspective: they have a very narrowly defined task. They are not designed for general purpose communication. For instance telephones were conceived for only for the purpose of voice transmission. However, this fact has been changing in recent years with the design of integrated services networks. These networks are designed to carry different types of communication including voice, data and video signals. Even systems with a single original purpose like telephony have been exploited for the transfer of other traffic, like data transfer for computers. Another development that has increased interest in general purpose communication is the internet. Once computers across the world began to be connected, the problem of incompatible networks became apparent. The OSI (Open Systems Interconnection) Reference Model was developed in an attempt to solve this compatibility problem. This model divides the communication system into seven layers which provide varying levels of service. The layers were intended to provide standard interfaces and services, so that various protocols, machines and network types could coexist.

Despite the spread of general purpose networking ideas, there are still many closed systems which have very specific purposes. In this environment, a simple and efficient protocol can be enforced without the danger of incompatibilities. An example is the network of devices in a modern automobile that communicate over a network. From the perspective of the author these narrowly defined closed systems are considered embedded communication systems. Even in these embedded systems, there is increasing interest in the connection of embedded systems to larger networks for status monitoring purposes. Just as the embedded systems have borrowed communication protocols and technology from larger communication systems, they are likely to borrow the many of the interconnection and standardization ideas in the near future.

The majority of embedded communication systems can be classified as either point-to-point networks (data links) or shared media networks (data highways). It is important to understand the trade-off between these two types of systems. In point-to-point networks, each node of the system is connected to every other node. These systems are simple and reliable. Reliability is high since correct transmission between two nodes only depends on a single transmitter and receiver. Since each link is dedicated to communication between two nodes, it is easy to meet real-time deadlines without any sophisticated scheduling mechanism. In shared media systems all nodes are connected together using a ring or bus topology. The primary motivation for shared media is the reduction in wiring (and thus cost). These networks are easily extendable without adding any new data ports to individual nodes. Limited new cabling is required.

The price for scalability and reduced cost of a shared media network is the complexity that must be added to the network protocol. Some means must be added to arbitrate for access to the shared media. The remaining discussion in this paper applies mainly to shared media embedded communication systems.

Source: Internet

Components of an Embedded System

An embedded system has three main components : Hardware, Software and time
operating system
i) Hardware

• Power Supply
• Processor
• Memory
• Timers
• Serial communication ports
• Output/Output circuits
• System application specific circuits

ii) Software: The application software is required to perform the series of tasks.
An embedded system has software designed to keep in view of three constraints:
• Availability of System Memory
• Availability of processor speed
• The need to limit power dissipation when running the system continuously in
cycles of wait for events, run , stop and wake up.
iii)  Real Time Operating System: (RTOS) It supervises the application software
and provides a mechanism to let the processor run a process as per scheduling and
do the switching from one process (task) to another process.

Source: Internet

Career in Embedded Technology

Many software professionals are now going for a career in embedded systems, the latest wave in technology. The communications industry is at an all – time high with embedded technology playing a crucial role in its advancement.

Professionals trained in embedded systems technologies happen to be a rare commodity in the recruitment market place. The demand for embedded systems engineers for product development and application will continue to grow in the years to come.

Embedded Technology is a combination of computer hardware, software and additional mechanisms, an embedded device is one in which the software is hidden in the hardware on which it runs. Embedded systems are designed to perform a specific function within a given time frame.

Embedded devices are found inside (besides PCs or workstations) in anything electronic that seems intelligent such as handheld devices like personal digital assistants PDAs, toys, automobiles, mobile phones, microwave ovens, music systems, digital cameras, access cards, TVs, MP3 players, ATMs, traffic signals and numerous other gadgets that we come across in our every day life.

Some other interesting scenarios in which embedded systems can be used are; Heating and lighting systems, which sense their surroundings and help minimize power consumption; Embedded software allows your washing machine to choose speed according to the type of cloth, gives thinking power to the microwave, acts like a music conductor in the car engine and pushes rocket launches into space.

Embedded systems are similar to memory chips with applications pre-loaded onto them. Once programmed, the software cannot be changed and this is what makes it different from Personal Computer. There is a lack of technical talent is this highly evolving and developing area.