Project Topics
Get Complete Project Material File(s) Now! »
NET Component Specification
.NET component built from a .NET project in the form of portable executable exe file or DLL file. .NET component’s interface consists properties, methods, and events that accessed by client applications. Basically, a .NET component consist pre-compiled set of classes that expose their services through the properties, methods, and events.
To build .NET component simple object-oriented programming involve – creating class, adding properties, methods, events in class. During execution, a .NET component is invoked and loaded into memory on request of client application. Most often, .NET component are developed and tested as independent .NET projects and pre-compiled DLL component can be added to other .NET applications as plug-in service providers.
Microsoft replaces Component Object Model (COM) technology due to its limitation by latest .NET Component Model technology. In .NET component model a new Microsoft Intermediate Language (MSIL) is introduced that is called Common Language Runtime (CLR). The functionality of CLR is alike a Java Virtual Machine [4].
In .NET component model programming languages approach is used to implement the internal structure as well as external view: component’s interfaces. In other words .NET component program control the external behaviour of component and internal structure of component at execution time is control by compiler. The external behaviour of component is related to communication and relationship with other components. The internal structure is related to functionality and capability that required by component.
In .NET component custom type definitions and interfaces are put in source code, instead of type libraries or Interface Definition Language (IDL). These type definitions are embedded by compiler in a specific format in .NET component assembly, called metadata. .NET component technology takes concept to a whole new level from COM type library concept. The type libraries described the definitions of COM component’s interfaces and provided a way to interact with components without involving source files but these type libraries had many shortcoming and problems. In .NET component metadata provides custom type, attributes, and base classes information in addition with information of type libraries. Fundamentally, metadata describe custom type definition and implemented interfaces of .NET components.
Real Time Systems
The real time systems are becoming pervasive in many domains of computer science application like Air Traffic Control Systems in defence, Network Multimedia Systems in mass communication, command control systems in field of embedded automotive electronics etc. The correctness behaviour of real time system depends upon logical results of the computation as well as on the physical instant at which outputs are produced. In environment, where real time systems are used produce physical material, state of real time system change after produced result. The classification of real time system based on many factors those include outside and inside computer system factors. Based on system response delay in deadline, real time systems are classified into soft real time systems and hard real time systems. In hard real time system missing deadline may leads to disasters or catastrophic, in soft real time system missing may deadline leads to a big and significant loss. In real time system most important concern is predictability of system behaviour and using static or dynamic scheduling of tasks in real time system we can achieved predictability of system behaviour. In static scheduling decisions are made at compile time or offline to check or test whether tasks can meet their deadlines and in dynamic scheduling decisions are made online [12].
Embedded Real Time Systems
The embedded real time systems being having hard timing and compact size requirements are considered to be really hard to modify. However recent trends of using embedded real time system in industry and other fields of life have showed that they can also be very well evolvable. Even some of them can continuously evolve over decades. Due to the growth of computer sciences and their extensive use in various fields of life, the research on how to make them more adjustable with the addition of new components and functionality is on demand.
Dependability is an area of major concern for embedded real time system. Research is going on how to make the components of embedded real time systems more and more independent. The independency between the components makes them more flexible to adapt to changes. The best way can be by separating the configuration of the systems from the services provided by the system. This way the system can evolve better and we can add more services to our system at less cost [12].
The development of Embedded Real Time Systems gives rise to a new software engineering approach called as the Component Based Software Engineering (CBSEs). It focuses on developing the system in different components and then to integrate those component while implementation. These way different components of the system can be made much more independent. Independency of the components helps the systems to be much more safe and easy to maintain. It will be easy to track faults and errors in a component of the system instead of the whole system. Similarly we can reduce the cost of our system by reusing the components of one system in another system over a period of time. Even the evolution or changes in one component without affecting the whole system is possible by the aid of Component Based Software Engineering (CBSE) approach.
Existing Component Technologies
The use of component technologies within embedded real time systems is much harder than in desktop applications. It is because of the hard timing requirements of the embedded real time systems. The embedded real time systems have to deliver right services at right time, which results in increasing the complexity of the system. Mostly the embedded real time systems are developed for some specific platforms. So it becomes difficult to reuse them on some other platforms. However some of the methods are already in use for software components reusability. The proxy service is a very common example of such methodology where the code of the components remains same, only the services have been used. In the next section, we will discuss some of the research and industrial methodologies that aid the reusability of the components. Selecting a particular technology depends upon various parameters such as the amount of information available, author claims the technology is best for embedded systems etc. Some common examples of such technologies are PECT, Koala, Rubus Component Model, PBO, PECOS and CORBA.
PECT
PECT is the term coined out to define that any component technology can be used if the rules used in its composition guarantees the runtime properties, by enforcing that the predictable patterns are used in construction. It is a project still going on at Software Engineering Institute (SEI) at the Carnegie Mellon University. It is a development infrastructure consisting of development tools and the analysis techniques. The rights of the users along with the expectations from the underlying technology are usually determined by the available analysis methods and the prediction goals. PECT has the independency of the underlying technology which makes it more portable and introducible. To understand the model properly, the underlying mapping technology needs to be properly understood [13].
Koala
It is a consumer electronic based component design method which is developed and used by one of the biggest Giant of Consumer Electronics named as Philips. It is economically very useful as the consumer electronics used cheap hardware to reduce the cost. The resource usage in Koala is made efficient and effective by the aid of thread sharing technique. It keeps the number of the thread low and it results into the low utilization of memory.
The koala has several special features that make it distinguishable from others. One of the important features is that all the components in Koala are source code components and are open for inspection. It aids the companies to find the functional errors and to perform the white box testing on them.
Since the Koala components are designed for particular consumer electronics. So they are much harder and it is difficult to introduce new technology within them. The components are tightly coupled to koala compiler and with the operating systems. The mechanism for communication and the interaction between components is similar to that of between components and the operating systems [13].
Rubus Component Model
It is the model most widely used in Volvo Construction Equipment. It is developed by the Arcticus along with the efforts of the research community. It is mainly used within system with real time requirements. The functionality is divided into two parts. The red represents the hard real time requirements. It is used for time-critical applications and is therefore time triggered in nature. The blue component represents the soft real time requirements and is event-triggered by nature. Rubus provides a very simple computation model for the control applications. It is very desirable model for hard and soft real time systems. The components of Rubus Model also contain the source-code components. These components are thus easy to inspect and test.
The constraint of probability can be considered as the requirement not met by the Rubus Component Model. It is also very tightly coupled with operating system. Being constructed on the very top of the Rubus Operating System, it’s hard to break the bound [13].
Port Based Objects (PBO)
It is developed at the Advanced Manipulators Laboratory at Carnegie Mellon University under the project called Chimera RTOS. It is a specialized development infrastructure used for the sensor based control systems applications along with the reconfigurable robotics applications. The minimization of communication and the synchronization among the components is a major objective of the design of PBO systems that facilitates the reusability of the components. It is very simple model to understand and work with both at the system level as well as component level. It too have the problem of tight coupling with Real Time Operating System, Chimera which makes it difficult to reuse the components in new systems. This dependency makes it less portable [13].
PECOS
It is mainly made to be used in field devices, i.e. embedded reactive systems. It is a nice example of collaboration between the industrial and research methods. This project looks out even the non functional requirements to be able to assess the properties during construction time very well. It does not have a special Integrated Development Environment (IDE). It based on the requirement of platform independence or probability.
To make the PECOS more attractive and computable, it is incorporated with the Unified Modeling Language (UML) for modeling the system. Since it is a research project focusing more on non functional properties, it is easily analyzable. However the source code is not presented in the components that make is less open. It uses black-box technologies for testing. However the use of white box testing is an area of going research [13].
CORBA Based Technologies
The Common Object Request Broker Architecture (CORBA) is a product of Object Management Group (OMG). Its main objective is to provide a platform that can be used for development of Object Management Group (OMG).
Different variant of CORBA exists in practice. The main reason for these diverse variant is that the CORBA required a lot of functionality to integrate the diverse platforms within a system. The two main variants of CORBA are Minimum CORBA and the Real Time CORBA. The Minimum CORBA is used within the resource constrains systems whereas the Real Time CORBA is used in time-critical systems.
An extended version of CORBA named as CORBA Component Model (CCM) has also been developed by OMG. It defines the features and the services of the components that help the developers to implement and manage components that can integrate the commonly used services. It serves as a mean of communication between the nodes that makes it more portable. It is powerful and needs very run-time requirements. Within the CORBA, the bindings of components and platform are performed at runtime. This makes difficult to fulfill the requirements of analyzability of components. CORBA systems are not well suitable for resource constraints systems as they perform dynamic binding. Dynamic binding is itself very much computation intense. Since CORBA is using the binary components, the inspection of it is quite impossible [8].
Software Component Services for Embedded Real-Time Systems
Component models are not very useful in the development and operations of Embedded Real Time Systems. The main reason is their dependence on time and the design that is based on binary components. To make them useful, the proxy service methodology is implemented. It helps to integrate the components without modifying their source code.
Some languages has built in functionality for proxy objects such as .NET has the .NET assembly and COM type library files which are used to implement component services. The code generate tool fulfils the need of code by generating the proxy code for such services automatically. Some common examples of such services are defined below [11];
• Logging Service: It determines the timing requirements and how the applications are executed. It defines the sequence of communication and messaging between the components.
• Time Execution Measurement Service: It takes the measurements of different timing requirements such as best case, worst case and the average case for the invocation and the execution of the services.
• Synchronization Service: It is used for synchronization of calls between the components. It plays a major role in integration of various components within a single system. There are two main types of synchronization policies implemented within a system. The mutual exclusion policy allows one thread to execute its functionality while blocking all other thread until the completion of its functionality. On completion the control is switched to other thread. The other one is the reader/writer policy. Here the read operations can execute concurrently by the distributing time among all the threads whereas the write operation have to execute exclusively.
• Execution Timeout Service: It is responsible for completing all the operation of the component of an embedded real time system within a specified period of time. That specified period is termed as the deadline for component. If the component fails to perform the functionality in time then the results will be really dangerous.
Table of contents :
Abstract
Perface
Acknowledgement
Chapter 1. Introduction
1.1 Problem Statement
1.2 Technology adaptation and Scope
1.3 Report Outline
Chapter 2 Component Based Software Engineering
2.1 Software Component
2.2 Component Models
2.2 Component Specification
2.2 .NET Component Specification
Chapter 3 Component Based Embedded Real Time Systems
3.1 Real Time Systems
3.2 Embedded Real Time Systems
3.3 Existing Component Technologies
3.3.1 PECT
3.3.2 Koala
3.3.3 Rubus Component Model
3.3.4 Port Based Objct (PBO)
3.3.5 PECOS
3.3.6 CORBA Based Technologies
3.4 Software Component Services for Embedded Real Time Systems
Chapter 4 Code Generation for Software Component Services in Smart Devices
4.1 Basic Concepts
4.1.1 Software Component Services
4.1.2 Proxy Object
4.1.3 Reading Metadata in .NET Assembly
4.1.4 Microsoft Visual Studio.NET Automation Object Model
4.1.4.1 Object Model Versions
4.1.4.2 Automation Categories
4.1.4.3 The DTE/DTE2 Root Object
4.1.4.4 Solution and Project Objects
4.2 Code Generator
4.2.1 Instruction to Generate Code
4.2.2 Testing and Validation
4.2.3 Limitation and Future Work
4.2.4 Related Work
Chapter 5 Conclusion
Chapter 6 References
