Architecting Embedded Software for Context-Aware Systems

During the last three decades the architecting of embedded software has changed by i ) the ever-enhancing processing performance of processors and their parallel usage, ii) design methods and languages, and iii) tools. The role of software has also changed as it has become a more dominant part of the embedded system. The progress of hardware development regarding size, cost and energy consumption is currently speeding up the appearance of smart environments. This necessitates the information to be distributed to our daily environment along with smart, but separate, items like sensors. The cooperation of the smart items, by themselves and with human beings, demands new kinds of embedded software.


Introduction
During the last three decades the architecting of embedded software has changed by i ) the ever-enhancing processing performance of processors and their parallel usage, ii) design methods and languages, and iii) tools.The role of software has also changed as it has become a more dominant part of the embedded system.The progress of hardware development regarding size, cost and energy consumption is currently speeding up the appearance of smart environments.This necessitates the information to be distributed to our daily environment along with smart, but separate, items like sensors.The cooperation of the smart items, by themselves and with human beings, demands new kinds of embedded software.
The architecting of embedded software is facing new challenges as it moves toward smart environments where physical and digital environments will be integrated and interoperable.The need for human beings to interact is decreasing dramatically because digital and physical environments are able to decide and plan behavior by themselves in areas where functionality currently requires intervention from human beings, such as showing a barcode to a reader in the grocery store.The smart environment, in our mind, is not exactly an Internet of Things (IoT) environment, but it can be.The difference is that the smart environment that we are thinking of does not assume that all tiny equipment is able to communicate via the Internet.Thus, the smart environment is an antecedent for the IoT environment.
At the start of the 1990s, hardware and software co-design in real time and embedded systems were seen as complicated matters because of integration of different modeling techniques in the co-design process (Kronlöf, 1993).In the smart environment, the co-design is radically changing, at least from the software perspective.This is due to the software needing to be more and more intelligent by, e.g., predicting future situations to offer relevant services for human beings.The software needs to be interoperable, as well as scattered around the environment, with devices that were previously isolated because of

The industrial evolution of the digital base station
Figure 1 shows the evolution of the Internet compared with a digital base station (the base station used from now on) for mobile networks.It also shows the change from proprietary interfaces toward open and Internet-based interfaces.In the 1990s, the base station was not built for communicating via the Internet.The base station was isolated in the sense that it was bound to a base station controller that controlled a group of base stations.That meant that a customer was forced to buy both the base stations and the base station controller from the same manufacturer.
In the 2000s, the industrial evolution brought the Internet to the base station and it opened the base station for module business by defining interfaces between modules.It also 125 dissolved the "engagement" between the base stations and their controllers as it moved from the second generation mobile network (2G) to third one (3G).Later, the baseband module of the base station was also reachable via the Internet.In the 2010s, the baseband module will go to the cloud to be able to meet the constantly changing capacity and coverage demands on the mobile network.The baseband modules will form a centralized baseband pool.These demands arise as smartphone, tablet and other smart device users switch applications and devices at different times and places (Nokia Siemens Networks, 2011).The evolution of base-band computing in the base station changes from distributed to centralized as a result of dynamicity.The estimation of needed capacity per mobile user was easier when mobiles were used mainly for phone calls and text messaging.The more fancy features that mobiles offer and users demand, the harder it is to estimate the needed baseband capacity.
The evolution of the base station goes hand-in-hand with mobile phones and other network elements, and that is the strength of the system architecture.The mobile network ecosystem has benefited a lot from the system architecture of, for example, the Global System for Mobile Communications (GSM).The context-aware system is lacking system architecture and that is hindering its breakthrough.

The standardization of mobile communication
During the 1980s, European telecommunication organizations and companies reached a common understanding on the development of a Pan-European mobile communication standard, the Global System for Mobile Communications (GSM), by establishing a dedicated organization, the European Telecommunications Standards Institute (ETSI, www.etsi.org),for the further evolvement of the GSM air-interface standard.This organization has produced the GSM900 and 1800 standard specifications (Hillebrand, 1999).The development of the GSM standard included more and more challenging features of standard mobile technology as defined by ETSI, such as High Speed Circuit Switched Data (HSCSD), General Packet Radio Service (GPRS), Adaptive Multirate Codec (AMR), and Enhanced Data rates for GSM Evolution (EDGE) (Hillebrand, 1999).

2005 2020
The Universal Mobile Telecommunication Syste m ( U M T S ) s h o u l d b e i n t e r p r e t e d a s a continuation of the regulatory regime and technological path set in motion through GSM, rather than a radical break from this regime.In effect, GSM standardization defined a path of progress through GPRS and EDGE toward UMTS as the major standard of 3G under the 3GPP standardization organization (Palmberg & Martikainen, 2003).The technological path from GSM to UMTS up to LTE is illustrated in The IoT ecosystem is lacking a standardization body, such as ETSI has been for the mobile networking ecosystem, to create the needed base for the business.However, there is the Internet of Things initiative (IoT-i), which is working and attempting to build a unified IoT community in Europe, www.iot-i.eu.

Design methods
The object-oriented approach became popular more than twenty years ago.It changed the way of thinking.Rumbaugh et al. defined object-oriented development as follows, i) it is a conceptual process independent of a programming language until the final stage, and ii) it is fundamentally a new way of thinking and not a programming technique (Rumbaugh et al., 1991).At the same time, the focus was changing from software implementation issues to software design.In those times, many methods for software design were introduced under the Object-Oriented Analysis (OOA) method (Shlaer & Mellor, 1992), the Object-Oriented Software Engineering (OOSE) method (Jacobson et al., 1992), and the Fusion method (Coleman et al., 1993).The Fusion method highlighted the role of entity-relationship graphs in the analysis phase and the behavior-centered view in the design phase.
The Object Modeling Technique (OMT) was introduced for object-oriented software development.It covers the analysis, design, and implementation stages but not integration and maintenance.The OMT views a system via a model that has two dimensions (Rumbaugh et al., 1991).The first dimension is viewing a system: the object, dynamic, or functional model.The second dimension represents a stage of the development: analysis, design, or implementation.The object model represents the static, structural, "data" aspects of a system.The dynamic model represents the temporal, behavioral, "control" aspects of a system.The functional model illustrates the transformational, "function" aspects of a system.Each of these models evolves during a stage of development, i.e. analysis, design, and implementation.
The OCTOPUS method is based on the OMT and Fusion methods and it aims to provide a systematic approach for developing object-oriented software for embedded real-time systems.OCTOPUS provides solutions for many important problems such as concurrency, synchronization, communication, interrupt handling, ASICs (application-specific integrated circuit), hardware interfaces and end-to-end response time through the system (Awad et al., 1996).It isolates the hardware behind a software layer called the hardware wrapper.The idea for the isolation is to be able to postpone the analysis and design of the hardware wrapper (or parts of it) until the requirements set by the proper software are realized or known (Awad et al., 1996).
The OCTOPUS method has many advantages related to the system division of the subsystems, but without any previous knowledge of the system under development the architect was able to end up with the wrong division in a system between the controlling and the other functionalities.Thus, the method was dedicated to developing single and solid software systems separately.The OCTOPUS, like the OMT, was a laborious method because of the analysis and design phases.These phases were too similar for there to be any value in carrying them out separately.The OCTOPUS is a top-down method and, because of that, is not suitable to guide bottom-up design as is needed in context-aware systems.
Software architecture started to become defined in the late 1980s and in the early 1990s.Mary Shaw defined that i) architecture is design at the level of abstraction that focuses on the patterns of system organization which describe how functionality is partitioned and the parts are interconnected and ii) architecture serves as an important communication, reasoning, analysis, and growth tool for systems (Shaw, 1990).Rumbaugh et al. defined software architecture as the overall structure of a system, including its partitioning into subsystems and their allocation to tasks and processors (Rumbaugh et al., 1991).Figure 2 represents several methods, approaches, and tools with which we have experimented and which have their roots in object-oriented programming.
For describing software architecture, the 4+1 approach was introduced by Philippe Krüchten.The 4+1 approach has four views: logical, process, development and physical.The last view, the +1 view, is for checking that the four views work together.The checking is done using important use cases (Krüchten, 1995).The 4+1 approach was part of the foundation for the Rational Unified Process, RUP.Since the introduction of the 4+1 approach software architecture has had more emphasis in the development of software systems.The most referred definition for the software architecture is the following one: The structure or structures of the system, which comprises software elements, the externally visible properties of those elements, and the relationships among them, (Bass et al., 1998) Views are important when documenting software architecture.Clements et al. give a definition for the view: "A view is a representation of a set of system elements and the relationships associated with them".Different views illustrate different uses of the software system.As an example, a layered view is relevant for telling about the portability of the software system under development (Clements, 2003).The views are presented using, for example, UML model elements as they are more descriptive than pure text.
Fig. 2. From object-oriented to design methods and supporting tools.
Software architecture has always has a role in base station development.In the beginning it represented the main separation of the functionalities, e.g.operation and maintenance, digital signal processing, and the user interface.Later on, software architecture was formulated via architectural views and it has been the window to each of these main functionalities, called software subsystems.Hence, software architecture is an efficient media for sharing information about the software and sharing the development work, as well.

Modeling
In the model-driven development (MDD) vision, models are the primary artifacts of software development and developers rely on computer-based technologies to transform models into running systems (France & Rumpe, 2007).The Model-Driven Architecture (MDA), standardized by the Object Management Group (OMG, www.omg.org), is an approach to using models in software development.MDA is a known technique of MDD.It is meant for specifying a system independently of the platform that supports it, specifying platforms, choosing a particular platform for the system, and transforming the system specification into a particular platform.The three primary goals of MDA are portability, interoperability and reusability through the architectural separation of concerns (Miller & Mukerji, 2003).
MDA advocates modeling systems from three viewpoints: computational-independent, platform-independent, and platform-specific viewpoints.The computational-independent viewpoint focuses on the environment in which the system of interest will operate in and on the required features of the system.This results in a computation-independent model (CIM).The platform-independent viewpoint focuses on the aspects of system features that are not likely to change from one platform to another.A platform-independent model (PIM) is used to present this viewpoint.The platform-specific viewpoint provides a view of a system in which platform-specific details are integrated with the elements in a PIM.This view of a system is described by a platform-specific model (PSM), (France & Rumpe, 2007).
The MDA approach is good for separating hardware-related software development from the application (standard-based software) development.Before the separation, the maintenance of hardware-related software was done invisibly under the guise of application development.By separating both application-and hardware-related software development, the development and maintenance of previously invisible parts, i.e., hardware-related software, becomes visible and measurable, and costs are easier to explicitly separate for the pure application and the hardware-related software.
Two schools exist in MDA for modeling languages: the Extensible General-Purpose Modeling Language and the Domain Specific Modeling Language.The former means Unified Modeling Language (UML) with the possibility to define domain-specific extensions via profiles.The latter is for defining a domain-specific language by using meta-modeling mechanisms and tools.The UML has grown to be a de facto industry standard and it is also managed by the OMG.The UML has been created to visualize object-oriented software but also used to clarify the software architecture of a subsystem that is not object-oriented.
The UML is formed based on the three object-oriented methods: the OOSE, the OMT, and Gary Booch's Booch method.A UML profile describes how UML model elements are extended using stereotypes and tagged values that define additional properties for the elements (France & Rumpe, 2007).A Modeling and Analysis of Real-Time Embedded Systems (MARTE) profile is a domain-specific extension for UML to model and analyze real time and embedded systems.One of the main guiding principles for the MARTE profile (www.omgmarte.org)has been that it should support independent modeling of both software or hardware parts of real-time and embedded systems and the relationship between them.OMG's Systems Modeling Language (SysML, www.omgsysml.org) is a general-purpose graphical modeling language.The SysML includes a graphical construct to represent text-based requirements and relate them to other model elements.
Microsoft Visio is usually used for drawing UML-figures for, for example, software architecture specifications.The UML-figures present, for example, the context of the software subsystem and the deployment of that software subsystem.The MARTE and SysML profiles are supported by the Papyrus tool.Without good tool support the MARTE profile will provide only minimal value for embedded software systems.
Based on our earlier experience and the MARTE experiment, as introduced in (Pantsar-Syväniemi & Ovaska, 2010), we claim that MARTE is not as applicable to embedded systems as base station products.The reason is that base station products are dependent on longterm maintenance and they have a huge amount of software.With the MARTE, it is not possible to i) model a greater amount of software and ii) maintain the design over the years.We can conclude that the MARTE profile has been developed from a hardware design point of view because software reuse seems to have been neglected.
Many tools exist, but we picked up on Rational Rhapsody because we have seen it used for the design and code generation of real-time and embedded software.However, we found that the generated code took up too much of the available memory, due to which Rational Rhapsody was considered not able to meet its performance targets.The hard real-time and embedded software denotes digital signal processing (DSP) software.DSP is a central part of the physical layer baseband solutions of telecommunications (or mobile wireless) systems, such as mobile phones and base stations.In general, the functions of the physical www.intechopen.com Embedded Systems -Theory and Design Methodology 130 layer have been implemented in hardware, for example, ASIC (application-specific integrated circuits), and FPGA (field programmable gate arrays), or near to hardware (Paulin et al., 1997), (Goossens et al., 1997).
Due to the fact that Unified Modeling Language (UML) is the most widely accepted modeling language, several model-driven approaches have emerged (Kapitsaki et al., 2009), (Achillelos et al., 2010).Typically, these approaches introduce a meta-model enriched with context-related artifacts, in order to support context-aware service engineering.We have also used UML for designing the collaboration between software agents and context storage during our research related to the designing of smart spaces based on the ontological approach (Pantsar-Syväniemi et al., 2011a, 2012).

Reuse and software product lines
The use of C language is one of the enabling factors of making reusable DSP software (Purhonen, 2002).Another enabling factor is more advanced tools, making it possible to separate DSP software development from the underlying platform.Standards and underlying hardware are the main constraints for DSP software.It is essential to note that hardware and standards have different lifetimes.Hardware evolves according to 'Moore's Law' (Enders, 2003), according to which progress is much more rapid than the evolution of standards.From 3G base stations onward, DSP software has been reusable because of the possibility to use C language instead of processor-specific assembly language.The reusability only has to do with code reuse, which can be regarded as a stage toward overall reuse in software development, as shown in Figure 3.
Regarding the reuse of design outputs and knowledge, it was the normal method of operation at the beginning of 2G base station software developments and was not too tightly driven by development processes or business programs.We have presented the characteristics of base station DSP software development in our previous work (Pantsar-Syväniemi et al., 2006) that is based on experiences when working at Nokia Networks.That work introduces the establishment of reuse actives in the early 2000s.Those activities were development 'for reuse' and development 'with reuse'.'For reuse' means development of reusable assets and 'with reuse' means using the assets in product development or maintenance (Karlsson, 1995).The main problem within this process-centric, 'for reuse' and 'with reuse', development was that it produced an architecture that was too abstract.The reason was that the domain was too wide, i.e., the domain was base station software in its entirety.In addition to that, the software reuse was "sacrificed" to fulfill the demand to get a certain base station product market-ready.This is paradoxical because software reuse was created to shorten products' time-to-market and to expand the product portfolio.The software reuse was due to business demands.
In addition to Karlsson's 'for and with reuse' book, we highlight two process-centric reuse books among many others.To design and use software architectures is written by Bosch (Bosch, 2000).This book has reality aspects when guiding toward the selection of a suitable organizational model for the software development work that was meant to be built around software architecture.In his paper, (Bosch, 1999), Bosch presents the main influencing factors for selecting the organization model: geographical distribution, maturity of project management, organizational culture, and the type of products.In that paper, he stated that a software product built in accordance with the software architecture is much more likely to fulfill its quality requirements in addition to its functional requirements.
Bosch emphasized the importance of software architecture.His software product line (SPL) approach is introduced according to these phases: development of the architecture and component set, deployment through product development and evolution of the assets (Bosch, 2000).He presented that not all development results are sharable within the SPL but there are also product-specific results, called artifacts.
The third interesting book introduces the software product line as compared to the development of a single software system at a time.This book shortly presents several ways for starting software development according to the software product line.It is written by Pohl et al. (Pohl et al., 2005) and describes a framework for product-line engineering.The book stresses the key differences of software product-line engineering in comparison with single-software system development:


The need for two distinct development processes: domain engineering and application engineering.The aim of the domain-engineering process is to define and realize the commonality and the variability of the software product line.The aim of the application-engineering process is to derive specific applications by exploiting the variability of the software product line.


The need to explicitly define and manage variability: During domain engineering, variability is introduced in all domain engineering artifacts (requirements, architecture, components, test cases, etc.).It is exploited during application engineering to derive applications tailored to the specific needs of different customers.
A transition from single-system development to software product-line engineering is not easy.It requires investments that have to be determined carefully to get the desired benefits (Pohl et al., 2005).The transition can be introduced via all of its aspects: process, development methods, technology, and organization.For a successful transition, we have to change all the relevant aspects, not just some of them (Pohl et al., 2005).With the base station products, we have seen that a single-system development has been powerful when products were more hardware-than software-oriented and with less functionality and complexity.The management aspect, besides the development, is taken into account in the www.intechopen.com Embedded Systems -Theory and Design Methodology 132 product line but how does it support long-life products needing maintenance over ten years?So far, there is no proposal for the maintenance of long-life products within the software product line.Maintenance is definitely an issue to consider when building up the software product line.
The strength of the software product line is that it clarifies responsibility issues in creating, modifying and maintaining the software needed for the company's products.In software product-line engineering, the emphasis is to find the commonalities and variabilities and that is the huge difference between the software product-line approach and the OCTOPUS method.We believe that the software product-line approach will benefit if enhanced with a model-driven approach because the latter strengthens the work with the commonalities and variabilities.
Based on our experience, we can identify that the software product-line (SPL) and modeldriven approach (MDA) alike are used for base station products.Thus, a combination of SPL and MDA is good approach when architecting huge software systems in which hundreds of persons are involved for the architecting, developing and maintaining of the software.A good requirement tool is needed to keep track of the commonalities and variabilities.The more requirements, the more sophisticated tool should be with the possibility to tag on the requirements based on the reuse targets and not based on a single business program.
The SPL approach needs to be revised for context-aware systems.This is needed to guide the architecting via the understanding of an eligible ecosystem toward small functionalities or subsystems.Each of these subsystems is a micro-architecture with a unique role.Runtime security management is one micro-architecture (Evesti & Pantsar-Syväniemi, 2010) that reuses context monitoring from the context-awareness micro-architecture, CAMA (Pantsar-Syväniemi et al., 2011a).The revision needs a new mindset to form reusable microarchitectures for the whole context-aware ecosystem.It is good to note that microarchitectures can differ in the granularity of the reuse.

Summary of section 2
The object-oriented methods, like Fusion, OMT, and OCTOPUS, were dedicated for singlesystem development.The OCTOPUS was the first object-oriented method that we used for an embedded system with an interface to the hardware.Both the OCTOPUS and the OMT were burdening the development work with three phases: object-oriented analysis (OOA) object-oriented design (OOD), and implementation.The OOD was similar to the implementation.In those days there was a lack of modeling tools.The message sequence charts (MSC) were done with the help of text editor.
When it comes to base station development, the software has become larger and more complicated with the new features needed for the mobile network along with the UML, the modeling tools supporting UML, and the architectural views.Thus, software development is more and more challenging although the methods and tools have become more helpful.
The methods and tools can also hinder when moving inside the software system from one subsystem to another if the subsystems are developed using different methods and tools.
Related to DSP software, the tight timing requirements have been reached with optimized C-code, and not by generating code from design models.Thus, the code generators are too ineffective for hard real time and embedded software.One of the challenges in DSP software is the memory consumption because of the growing dynamicity in the amount of data that flows through mobile networks.This is due to the evolution of mobile network features like HSDPA and HSUPA that enable more features for mobile users.The increasing dynamicity demands simplification in the architecture of the software system.One of these simplifications is the movement from distributed baseband computing to centralized computing.
Simplification has a key role in context-aware computing.Therefore, we recall that by breaking the overall embedded software architecture into smaller pieces with specialized functionality, the dynamicity and complexity can be dealt with more easily.The smaller pieces will be dedicated micro-architectures, for example, run-time performance or security management.We can see that in smart environments the existing wireless networks are working more or less as they currently work.Thus, we are not assuming that they will converge together or form only one network.By taking care of and concentrating the data that those networks provide or transmit, we can enable the networks to work seamlessly together.Thus, the networks and the data they carry will form the basis for interoperability within smart environments.The data is the context for which it has been provided.Therefore, the data is in a key position in context-aware computing.
The MSC is the most important design output because it visualizes the collaboration between the context storage, context producers and context consumers.The OCTOPUS method is not applicable but SPL is when revised with micro-architectures, as presented earlier.The architecting context-aware systems need a new mindset to be able to i) handle dynamically changing context by filtering to recognize the meaningful context, ii) be designed bottom-up, while keeping in mind the whole system, and iii) reuse the legacy systems with adapters when and where it is relevant and feasible.

Architecting real-time and embedded software in the smart environment
Context has always been an issue but had not been used as a term as widely with regard to embedded and real-time systems as it has been used in pervasive and ubiquitous computing.Context was part of the architectural design while we created architectures for the subsystem of the base station software.It was related to the co-operation between the subsystem under creation and the other subsystems.It was visualized with UML figures showing the offered and used interfaces.The exact data was described in the separate interface specifications.This can be known as external context.Internal context existed and it was used inside the subsystems.
Context, both internal and external, has been distributed between subsystems but it has been used inside the base station.It is important to note that external context can be context that is dedicated either for the mobile phone user or for internal usage.The meaning of context that is going to, or coming from, the mobile phone user is meaningless for the base station but it needs memory to be processed.In pervasive computing, external context is always meaningful and dynamic.The difference is in the nature of context and the commonality is in the dynamicity of the context.
Recent research results into the pervasive computing state that:  (Truong & Dustdar, 2009)  development of context-aware applications is complex as there are many software engineering challenges stemming from the heterogeneity of context information sources, the imperfection of context information, and the necessity for reasoning on contextual situations that require application adaptations (Indulska & Nicklas, 2010)  proper understanding of context and its relationship with adaptability is crucial in order to construct a new understanding for context-aware software development for pervasive computing environments (Soylu et al., 2009)  ontology will play a crucial role in enabling the processing and sharing of information and knowledge of middleware (Hong et al., 2009)

Definitions
Many definitions for context as well for context-awareness are given in written research.The generic definition by Dey and Abowd for context and context-awareness are widely cited (Dey & Abowd, 1999): 'Context is any information that can be used to characterize the situation of an entity.An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and the application themselves.' 'Context-awareness is a property of a system that uses context to provide relevant information and/or services to the user, where relevancy depends on the user's task.' Context-awareness is also defined to mean that one is able to use context-information (Hong et al., 2009).Being context-aware will improve how software adapts to dynamic changes influenced by various factors during the operation of the software.Context-aware techniques have been widely applied in different types of applications, but still are limited to small-scale or single-organizational environments due to the lack of well-agreed interfaces, protocols, and models for exchanging context data (Truong & Dustdar, 2009).
In large embedded-software systems the user is not always the human being but can also be the other subsystem.Hence, the user has a wider meaning than in pervasive computing where the user, the human being, is in the center.We claim that pervasive computing will come closer to the user definition of embedded-software systems in the near future.Therefore, we propose that 'A context defines the limit of information usage of a smart space application' (Toninelli et al., 2009).That is based on the assumption that any piece of data, at a given time, can be context for a given smart space application.

Designing the context
Concentrating on the context and changing the design from top-down to bottom-up while keeping the overall system in the mind is the solution to the challenges in the context-aware computing.Many approaches have been introduced for context modeling but we introduce one of the most cited classifications in (Strang & Linnhoff-Popien, 2004):

Key-Value Models
The model of key-value pairs is the most simple data structure for modeling contextual information.The key-value pairs are easy to manage, but lack capabilities for sophisticated structuring for enabling efficient context retrieval algorithms.

Markup Scheme Models
Common to all markup scheme modeling approaches is a hierarchical data structure consisting of markup tags with attributes and content.The content of the markup tags is usually recursively defined by other markup tags.Typical representatives of this kind of context modeling approach are profiles.

Graphical Model
A very well-known general purpose modeling instrument is the UML which has a strong graphical component: UML diagrams.Due to its generic structure, UML is also appropriate to model the context.

Object-Oriented Models
Common to object-oriented context modeling approaches is the intention to employ the main benefits of any object-oriented approach -namely encapsulation and reusabilityto cover parts of the problems arising from the dynamics of the context in ubiquitous environments.The details of context processing are encapsulated on an object level and hence hidden to other components.Access to contextual information is provided through specified interfaces only.

Logic-Based Models
A logic defines the conditions on which a concluding expression or fact may be derived (a process known as reasoning or inferencing) from a set of other expressions or facts.
To describe these conditions in a set of rules a formal system is applied.In a logic-based context model, the context is consequently defined as facts, expressions and rules.Usually contextual information is added to, updated in and deleted from a logic based system in terms of facts or inferred from the rules in the system respectively.Common to all logic-based models is a high degree of formality.

Ontology-Based Models
Ontologies are particularly suitable to project parts of the information describing and being used in our daily life onto a data structure utilizable by computers.Three ontology-based models are presented in this survey: i) Context Ontology Language (CoOL), (Strang et al., 2003); ii) the CONON context modeling approach (Wang et al., 2004); and iii) the CoBrA system (Chen et al., 2003a).
The survey of context modeling for pervasive cooperative learning covers the abovementioned context modeling approaches and introduces a Machine Learning Modeling (MLM) approach that uses machine learning (ML) techniques.It concludes that to achieve the system design objectives, the use of ML approaches in combination with semantic context reasoning ontologies offers promising research directions to enable the effective implementation of context (Moore et al., 2007). www.intechopen.com Embedded Systems -Theory and Design Methodology 136 The role of ontologies has been emphasized in multitude of the surveys, e.g., (Baldauf et al., 2007), (Soylu et al., 2009), (Hong et al., 2009), (Truong & Dustdar, 2009).The survey related to context modeling and reasoning techniques (Bettini et al., 2010) highlights that ontological models of context provide clear advantages both in terms of heterogeneity and interoperability.Web Ontology Language, OWL, (OWL, 2004) is a de facto standard for describing context ontology.OWL is one of W3C recommendations (www.w3.org) for a Semantic Web.Graphical tools, such as Protégé and NeOnToolkit, exist for describing ontologies.

Context platform and storage
Eugster et al. present the middleware classification that they performed for 22 middleware platforms from the viewpoint of a developer of context-aware applications (Eugster et al., 2009).That is one of the many surveys done on the context-aware systems but it is interesting because of the developer viewpoint.They classified the platforms according to i) the type of context, ii) the given programming support, and iii) architectural dimensions such as decentralization, portability, and interoperability.The most relevant classification criteria of those are currently the high-level programming support and the three architectural dimensions.
High-level programming support means that the middleware platform adds a context storage and management.The three architectural dimensions are: (1) decentralization, (2) portability, and (3) interoperability.Decentralization measures a platform's dependence on specific components.Portability classifies platforms into two groups: portable platforms can run on many different operating systems, and operating system-dependent platforms, which can only run on few operating systems (usually one).Interoperability then measures the ease with which a platform can communicate with heterogeneous software components.
Ideal interoperable platforms can communicate with many different applications, regardless of the operating system on which they are built or of the programming language in which they are written.The IOP is proposed to be extended, where and when needed, with context-aware functionalities following 'the separation of concern' principle to keep application free of the context (Toninelli et al., 2009).
Kuusijärvi and Stenius illustrate how reusable KPs can be designed and implemented, i.e., how to apply 'for reuse' and 'with reuse' practices in the development of smart environments (Kuusijärvi & Stenius, 2011).Thus, they cover the need for programming level reusability.

Context-aware micro-architecture
When context information is described by OWL and ontologies, typically reasoning techniques will be based on a semantic approach, such as SPARQL Query Language for RDF (SPARQL), (Truong & Dustdar, 2009).The context-monitoring agent is configured via configuration parameters which are defined by the architect of the intelligent application.The configuration parameters can be updated at run-time because the parameters follow the used context.The configuration parameters can be given by the ontology, i.e., a set of triples to match, or by a SPARQL query, if the monitored data is more complicated.The idea is that the context monitoring recognizes the current status of the context information and reports this to the semantic database.Later on, the reported information can be used in decision making.
The rule-based reasoning agent is based on a set of rules and a set of activation conditions for these rules.In practice, the rules are elaborated 'if-then-else' statements that drive activation of behaviors, i.e., activation patterns.The architect describes behavior by MSC diagrams with annotated behavior descriptions attached to the agents.Then, the behavior is transformed into SPARQL rules by the developer who exploits the MSC diagrams and the defined ontologies to create SPARQL queries.The developer also handles the dynamicity of the space by providing the means to change the rules at run-time.The context reasoning is a fully dynamic agent, whose actions are controlled by the dynamically changing rules (at run-time).
If the amount of agents producing and consuming inferred information is small, the rules can be checked by hand during the development phase of testing.If an unknown amount of agents are executing an unknown amount of rules, it may lead to a situation where one rule affects another rule in an unwanted way.A usual case is that two agents try to change the state of an intelligent object at the same time resulting in an unwanted situation.Therefore, there should be an automated way of checking all the rules and determining possible problems prior to executing them.Some of these problems can be solved by bringing priorities into the rules, so that a single agent can determine what rules to execute at a given time.This, of course, implies that only one agent has rules affecting certain intelligent objects.
CAMA has been used: The Context Ontology for Smart Spaces, (CO4SS), is meant to be used together with the CAMA.It has been developed because the existing context ontologies were already few years old and not generic enough (Pantsar-Syväniemi et al, 2012).The objective of the CO4SS is to support the evolution management of the smart space: all smart spaces and their applications 'understand' the common language defined by it.Thus, the context ontology is used as a foundational ontology to which application-specific or run-time quality management concepts are mapped.

Conclusion
The role of software in large embedded systems, like in base stations, has changed remarkably in the last three decades; software has become more dominant compared to the role of hardware.The progression of processors and compilers has prepared the way for reuse and software product lines by means of C language, especially in the area of DSP software.Context-aware systems have been researched for many years and the maturity of the results has been growing.A similar evolution has happened with the object-oriented engineering that comes to DSP software.Although the methods were mature, it took many years to gain proper processors and compilers that support coding with C language.This shows that without hardware support there is no room to start to use the new methods.
The current progress of hardware development regarding size, cost and energy consumption is speeding up the appearance of context-aware systems.This necessitates that the information be distributed to our daily environment along with smart but separated things like sensors.The cooperation of the smart things by themselves and with human beings demands new kinds of embedded software.The new software is to be designed by the ontological approach and instead of the process being top-down, it should use the bottom-up way.The bottom-up way means that the smart space applications are formed from the small functionalities, micro-architecture, which can be configured at design time, on instantiation time and during run-time.
The new solution to designing the context management of context-aware systems from the bottom-up is context-aware micro-architecture, CAMA, which is meant to be used with CO4SS ontology.The CO4SS provides generic concepts of the smart spaces and is a common 'language'.The ontologies can be compared to the message-based interface specifications in the base stations.This solution can be the grounds for new initiatives or a body to start forming the 'borders', i.e., the system architecture, for the context-aware ecosystem.

Fig. 1 .
Fig. 1.The evolution of the base station.

Fig. 3 .
Fig. 3. Toward the overall reuse in the software development.
The context-awareness micro-architecture, CAMA, is the solution for managing adaptation based on context in smart environments.Context-awareness micro-architecture consists of three types of agents: context monitoring, context reasoning and context-based adaptation agents(Pantsar-Syväniemi et al., 2011a).These agents share information via the semantic database.Figure4illustrates the structural viewpoint of the logical context-awareness micro-architecture.


to activate required functionality according to the rules and existing situation(s) (Pantsar-Syväniemi et al., 2011a)  to map context and domain-specific ontologies in a smart maintenance scenario for a context-aware supervision feature (Pantsar-Syväniemi et al., 2011b)  in run-time security management for monitoring situations (Evesti & Pantsar-Syväniemi, 2010)

Table 1 .
The technological path of the mobile communication system It is remarkable that standards have such a major role in the telecommunication industry.
They define many facts via specifications, like communication between different parties.The European Telecommunications Standards Institute (ETSI) is a body that serves many players such as network suppliers and network operators.Added to that, the network suppliers have created industry forums: OBSAI (Open Base Station Architecture Initiative) and CPRI (Common Public Radio Interface).The forums were set up to define and agree on open standards for base station internal architecture and key interfaces.This, the opening of the internals, enabled new business opportunities with base station modules.Thus, module vendors were able to develop and sell modules that fulfilled the open, but specified, interface and sell them to base station manufacturers.In the beginning the OBSAI was heavily driven by Nokia Networks and the CPRI respectively by Ericsson.Nokia Siemens Networks joined CPRI when it was merged by Nokia and Siemens.
This kind of InterOperabilility Platform (IOP) is developed in the SOFIA-project (www.sofia-project.eu).The IOP's context storage is a Semantic Information Broker (SIB), which is a Resource Description Framework, RDF, (RDF, 2004) database.Software agents which are called Knowledge Processors (KP) can connect to the SIB and exchange information through an XML-based interaction protocol called Smart Space Access Protocol (SSAP).KPs use a Knowledge Processor Interface (KPI) to communicate with the SIB.KPs consume and produce RDF triples into the SIB according to the used ontology.