**1. Introduction**

22 Real-Time Systems, Architecture, Scheduling, and Application

Deborah Estrin (2001). Embedded Everywhere: A Research Agenda for Networked Systems of Embedded Computers, National Academy Press, ISBN 0-309-07568-8 Redwan Salami et al. (2002). The Adaptive Multi-Rate Codec: History and Performance,

Johan Sjöberg et al. (2002). Real-Time Transport Protocol (RTP) Payload Format and File

Gregory Pottie and William Kaiser (2005). Principles of Embedded Networked Systems

Adam Dunkels (2005). Towards TCP/IP for Wireless Sensor Networks, Ed. Arkitektkopia,

Analog Devices (2006). ADSP-BF533: Blackfin Embedded Processor DataSheet, Rev. C.,

Analog Devices 1 (2007). VisualDSP++ 5.0 Device Drivers and System Services Manual for

Sorin Zoican (2008). The Role of Programmable Digital Signal Processors (DSP) for 3G

Analog Devices 1 (2010). VisualDSP++ 5.0 C/C++ Compiler and Library Manual for

Sorin Zoican (2011). The Adaptive Multirate Speech Codec: Deployment Strategy Using the

Technology and Human - Computer Dialogue, Brasov, Romania, pp. 81-84.

John Proakis, Charles Rader, and Fuyun Ling (1992). Advanced Topics in Digital Signal

Arnold Berger (2001), Embedded Systems Design: An Introduction to Processes, Tools and

John Catsoulis and O'Reilly (2005). Designing Embedded Hardware, O'Reilly Media, ISBN

Douglas Comer (1993). Internetworking with TCP/IP - Principles, Protocols and

Mobile Communication Systems, Acta Tehnica Napocensis, Electronic and

Blackfin Microcomputer", Sped 2011 - The proceedings of 6th Conference on Speech

Analog Devices 2 (2007). VisualDSP 5.0 Kernel (VDK) Users Guide, www.analog.com Adam Dunkels (2007). Programming Memory-Constrained Networked Embedded Systems, SICS Dissertation Series 47, Ed. Arkitektkopia, Vasteras, Sweden, ISSN 1101-1335 Woon-Seng Gan. and Sen M. Kuo, (2007). Embedded Signal Processing with the Micro

Signal Architecture, Wiley-Interscience, ISBN 978-0471738411

Telecommunications, vol. 49, no. 3, 2008, pp.49-56

Processing, Prentice Hall, ISBN: 0-02-396841-9

Techniques, CPM Books, ISBN 1-800-788-3123

Architecture, Prentice Hall, 1993, ISBN 86-7991-142-9

Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate

IEEE Speech Coding Workshop, Tsukuba, Japan, pp. 144–146

Wideband (AMR-WB) Audio Codecs, IETF RFC 3267

Vasteras, Sweden, ISBN 91-88834-96-4

Blackfin Processors, www.analog.com

Blackfin Processors, www.analog.com Analog Devices 2 (2010). LWIP user guide, www.analog.com

www.analog.com

**Additional readings** 

0-596-00755-8

Design, Cambridge University Press, ISBN 9780521840125

**7. References** 

A system is built to serve a common purpose of an organization or a network; it usually consists of a set of operations, interfaces for inputs and outputs, and a group of users with direct or indirect interactions. Systems exist in nature as well as in virtually any conceivable area of human society (Dori, 2003). We are surrounded by systems which undergo changes over time and experience some sort of evolutionary pressure. In order to formulate a system with its specifications, a complete set of updated requirements is established before delving further into the development process. Here the presumption is that, based on the specified requirements, the system would adequately serve the underlying community within its predefined life cycle. However, like any other objects or materials, the system will gradually become outdated over an extended period of time (unless any newly emerged requirements are addressed); this is due to the changes in its surrounding environment, which includes end users, groups of people involved through meetings or other common interests, their mutual interactions with other systems or exchange of information through social networks, related auxiliary or dependent systems and its type of services to the community. In the end, the system will lose its value over a period of time and it is a common fact, but unavoidable scenario, unless explicit measures are taken for re-configuring the system with new specifications. In other words, the current expiring features need to be replaced with newly emerged requirements so that it can maintain its efficacy and remain competitive in the market. Traditional systems do not have such capabilities to address emerging requirements. These systems either need to be thoroughly re-engineered, or simply replaced with a new system. Both of these options are very expensive in all aspects. With the help of a "*Wrapper system,*" if a system can identify these upcoming requirements and able to direct necessary changes into the system itself by dynamically adjusting its specifications, then it will be in a good standing to extend its life cycle, and maintain a higher level of user satisfaction through its dynamic configurations. A wrapper system is a real-time system itself; it is a carefully formulated meta-structure to address dynamic configurability. In this setup, the target system can be termed an "*Evolvable system*" which, via its adaptability, gradually makes a valuable return of investment over an extended software lifetime.

Dynamics of System Evolution 25

pre-configured meta-data from various junction points in the workflow, as well as from its surrounding environment. It can also provide real-time analytics and the flexibilities in deducing meta-models for dynamic configuration of system specifications. Having a supporting sub-system can also enable the architects, designers, developers and stakeholders to have real-time snap-shots of system states. At any instant of time they can view how well the system is performing its services, examine the current workload of the system, track the history of system usage patterns, and detemine imminent changes. Moreover, it can provide clear insight into the system and collect important feedbacks and analytics for necessary changes being applied into the system. These capabilities are the *primary constituent elements* of an evolvable system. In this way, a newly built system is expected to have a way to adapt with any additional future requirements that were imperceptible at the time of initial system design. These new requirements gradually emerge by frequent and recurring usages of the system surrounded by an operating

The primary goal here is to be able to address these newly emerged requirements and then apply them into the system already in production so that it can continue to meet the incremental needs of the end users. To implement such versatile capabilities into a system requires a set of additional supporting components that will efficiently capture detailed system usage patterns throughout its operating workflow and, implicitly collect new system requirements from users by survey agents, automated collection of system usage patterns, and random voluntary feedback over a period of time. It is vital to look for any evolutionary changes, or indications through carefully analyzing the meta-data collected from the system. The objective is to be able to reflect in its behavior any ongoing changes in the surrounding environment so that it may continue to serve satisfactorily with a high value of return in the

In this chapter, we discuss the development efforts to identify general terms and metrics that are necessary to track a system's upcoming evolutionary phases. We present higherlevel analyses of these metrics through examples of several years of systems development track history and usage data in multiple projects in order to discover any significant implications of applying new changes towards their extended system lifecycle. Based on our rigorous observation, we also derived a preliminary methodology to formulate system dynamics towards their evolution, which can be followed or modified as needed for the

Evolution is often an intrinsic, feedback-driven, property of a software-based system. The meta-structure (as mentioned in Section 1), within which a system evolves, contains a number of feedback relationships (we will see more details in Section 3). The organization and environmental feedbacks transmit the evolutionary pressure to yield the continuing change in the process. The rate at which a program executes, the frequency of usage, user interactions with the operating environment, and economic and social dependencies of external processes on the system in production-all these cause its deficiencies be exposed over a period of time (Lehman, 1980). Therefore, these deficiencies to eventually become

environment over a long period of time.

purpose of building evolvable systems.

**2. Evolvable systems** 

competitive market.

Normally, when a system is built and deployed into a production environment, it becomes very difficult to change or upgrade it. Additionally, to take down the service for maintenance or upgrade without the complete knowledge of the problem scope, is also very expensive. Several examples of these non-evolvable traditional systems are listed below:


Without the options for reconfigurations to meet these shortfalls, the above mentioned systems cannot be termed as evolvable systems since it will be very difficult to make necessary changes outside of their preset functionalities. Such rigid and non-configurable systems will become outdated at some point and will need to be replaced with newer versions. Otherwise, some continued laborious support will need to be provided to go on with the current settings. To avoid this, a system should be as dynamically reconfigurable as possible. It opens up a wide range of opportunities to address many emerging requirements through fine tuning specifications from any desirable perspective.

Building a system itself is not enough; the main exhaustive part emerges from the great effort to sustain and keep pace with ongoing demands. Surveys indicate that on average as much as 70% of projects software budget is devoted to maintenance activity over the life of the software (Port, 1988; Bennet, 1990). Maintenance of any system is inevitable, either to enhance the system by altering its functionality, or to adapt the system to cope with the changes in the environment; to correct newly discovered errors, or to update the system in anticipation of any future problems. Therefore, it is becoming increasingly important to consider future system maintenance activity as it is designed and developed (Ferneley, 1998).

Our area of concentration for the study of system dynamics focuses on software-driven processes in general, because they have the capability of automatically collecting system's 24 Real-Time Systems, Architecture, Scheduling, and Application

Normally, when a system is built and deployed into a production environment, it becomes very difficult to change or upgrade it. Additionally, to take down the service for maintenance or upgrade without the complete knowledge of the problem scope, is also very expensive. Several examples of these non-evolvable traditional systems are listed below:

• *Vending Machines* -- lack the ability to track purchase rates, assess current inventory and automatically notify when it is necessary to reorder. These also lack the ability to capture the underlying changing patterns of seasonal purchasing habits for that

• *Microwave Ovens* -- lack the ability to assess the weight-volume of the food, and the intensity or duration of cooking, and it cannot track heating patterns of meals in a

• *Elevator systems* -- lack the ability to learn and communicate with other elevators, to assess load balancing, deduce operation schedules based on usage patterns and cannot

• *OBD Code Readers* -- lack the ability to suggest the probable cause(s) of the problem from previous history, predict any upcoming related issues, or inform the manufacturer with the estimated fault rate of certain parts so that their next model can eliminate any

• *Document Management Systems* -- lack the ability to generalize the identification of input locations of data fields in the paper-based forms with the help of OCR-texts accordingly

• *Security System of Buildings* -- lacks the ability to identify and track object movements or sounds generated from certain areas, and to capture occupancy patterns by observing

Without the options for reconfigurations to meet these shortfalls, the above mentioned systems cannot be termed as evolvable systems since it will be very difficult to make necessary changes outside of their preset functionalities. Such rigid and non-configurable systems will become outdated at some point and will need to be replaced with newer versions. Otherwise, some continued laborious support will need to be provided to go on with the current settings. To avoid this, a system should be as dynamically reconfigurable as possible. It opens up a wide range of opportunities to address many emerging requirements through fine tuning specifications from any desirable

Building a system itself is not enough; the main exhaustive part emerges from the great effort to sustain and keep pace with ongoing demands. Surveys indicate that on average as much as 70% of projects software budget is devoted to maintenance activity over the life of the software (Port, 1988; Bennet, 1990). Maintenance of any system is inevitable, either to enhance the system by altering its functionality, or to adapt the system to cope with the changes in the environment; to correct newly discovered errors, or to update the system in anticipation of any future problems. Therefore, it is becoming increasingly important to consider future system maintenance activity as it is designed and developed (Ferneley,

Our area of concentration for the study of system dynamics focuses on software-driven processes in general, because they have the capability of automatically collecting system's

and cannot suggest probable filing destinations in the database.

notify when it is the right time for maintenance.

locality.

household.

perspective.

1998).

such issues in the future.

and comparing over a period of time.

pre-configured meta-data from various junction points in the workflow, as well as from its surrounding environment. It can also provide real-time analytics and the flexibilities in deducing meta-models for dynamic configuration of system specifications. Having a supporting sub-system can also enable the architects, designers, developers and stakeholders to have real-time snap-shots of system states. At any instant of time they can view how well the system is performing its services, examine the current workload of the system, track the history of system usage patterns, and detemine imminent changes. Moreover, it can provide clear insight into the system and collect important feedbacks and analytics for necessary changes being applied into the system. These capabilities are the *primary constituent elements* of an evolvable system. In this way, a newly built system is expected to have a way to adapt with any additional future requirements that were imperceptible at the time of initial system design. These new requirements gradually emerge by frequent and recurring usages of the system surrounded by an operating environment over a long period of time.

The primary goal here is to be able to address these newly emerged requirements and then apply them into the system already in production so that it can continue to meet the incremental needs of the end users. To implement such versatile capabilities into a system requires a set of additional supporting components that will efficiently capture detailed system usage patterns throughout its operating workflow and, implicitly collect new system requirements from users by survey agents, automated collection of system usage patterns, and random voluntary feedback over a period of time. It is vital to look for any evolutionary changes, or indications through carefully analyzing the meta-data collected from the system. The objective is to be able to reflect in its behavior any ongoing changes in the surrounding environment so that it may continue to serve satisfactorily with a high value of return in the competitive market.

In this chapter, we discuss the development efforts to identify general terms and metrics that are necessary to track a system's upcoming evolutionary phases. We present higherlevel analyses of these metrics through examples of several years of systems development track history and usage data in multiple projects in order to discover any significant implications of applying new changes towards their extended system lifecycle. Based on our rigorous observation, we also derived a preliminary methodology to formulate system dynamics towards their evolution, which can be followed or modified as needed for the purpose of building evolvable systems.
