1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

Abstract-- One of the concepts of smart grid is to have direct

communication from power utilities to communities with immediate response for critical electricity situation. Smart Energy Home Area Network (SE HAN) devices having the ability to response for demands from power utilities are important parts of the smart grid network. ZigBee Smart Energy Profile (SEP) is widely used for trial and pilot programs but it is in the process of evolving into newer specification for final deployment to cater a wider scope of technologies together with the support of IPV6. There is a great deal of work for the industry to support the rapid change of profiles within a short period of time. This paper proposes a scalable architecture of embedded software design for SE HAN devices that can help the reuse of software to cope with the fast evolution of SEP definition.

Index Terms-- Smart Energy, End Devices, Embedded Software, Reuse, Architectural framework

I. INTRODUCTION HE concept of implementing smart grid through demand response and load control protocol (DRLC) was realized through the finalization of ZigBee Smart

Energy Profile version 1.0 (SEP 1.0) in 2008. Industry started to develop standard SEP compliance devices through ZigBee certification program. As this is a very new technology so the profile has been continuously evolving. Most of the utility companies are using SEP 1.0 or current version 1.1 for their trial or pilot run to test out the smart grid concept. However, such profile will have major change to version 2.0 to cope with wider wireless or power line carrier technologies and also IPV6 [1]. The overall structure of SEP 2.0 may be very different from SEP 1.0/1.1. Implementing SEP 2.0 demands a much higher processing capability than implementing SEP 1.0/1.1 therefore this may likely affect not just software change but even hardware design.

Embedded software are usually developed with tight coupling with the hardware drivers in order to meet the non-function requirement, such as, memory constraint and clock speed [2]. Therefore, if the development of the embedded software for SEP supported devices is based on traditional approach, it is very likely to take a great deal of effort to migrate the software developed from existing devices to the new one when the new profile is finalized.

This paper reviews the current software design architecture of SE HAN devices and proposes a scalable modular

W. Ha is with the Computime Ltd. of Hong Kong (e-mail:

wlha@netvigator.com) H. Sun is with the Department of Systems Engineering and Engineering

Management of City University of Hong Kong (e-mail: mehsun@cityu.edu.hk)

architecture to facilitate the reuse of most of them when there is further evolution of the SEP.

The rest of this paper is organized as the follows. The next section will review the limitation of current software architecture design and the problems of applying such design with different SE HAN devices hardware configurations. Section 3 reviews different type of software architectures for embedded system and the applicability to SE HAN devices. Section 4 discusses the proposed architecture to solve the current problem. Section 5 will further elaborate the architecture with a case study. Section 6 provides a brief conclusion of the work and achievement of the architecture in applying to the embedded software development of SE HAN devices.

II. CURRENT SOFTWARE DESIGN ARCHITECTURE AND LIMITATION

The architecture of ZigBee network consists of three basic levels: 1) Network Level, 2) Infrastructure Level and 3) Application Level. Network Level handles addressing, routing and formation; infrastructure level handles service discovery and security; application level handles pricing, messaging and demand response [3]. Usually, RF chipset suppliers will provide network level and infrastructure level as the stack layer. For application level, it is the smart energy profile (SEP), RF chipset suppliers will provide a profile framework with different clusters to SE HAN devices developers. Clusters are the detail protocol of the SEP that implements smart energy related functions. There are four major clusters defined that related to SE HAN devices: 1) Demand Response and Load Control (DRLC), 2) Price, 3) Message and 4) Simple Metering.

Figure 1 High level Simplified Software Architecture for SE HAN

devices For SE HAN devices development, usually, HAN devices

developers add their software codes to the profile framework to handle the clusters and process the related

Reusable Architecture for Embedded Software of Smart Energy HAN Devices Waileung Ha, Member, IEEE, and Hongyi Sun, Senior Member, IEEE

T

IEEE PES ISGT ASIA 2012 1569536201

1

1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

demand or information from power utility. Figure 1 shows a high level simplified view of the architecture. As the Stack Layer which consists of Network Level and Infrastructure Level implementation mostly provided by RF Chipset suppliers, so this paper will focus on the discussion of Application Level as this is the key focus of SE HAN devices developers for their software code development.

Based on traditional embedded software development, the profile framework, clusters handler, control algorithm, sensing logic and hardware drivers are tightly coupled together.

shows the simplified software architecture of a typical SE HAN device.

Figure 2 Simplified traditional architecture for SE HAN device

When there is any revision of the SEP, it will cause a

newer revision of the profile framework. With the ripple effect [4], the cluster change will induce changes on both the Handler and Hardware Drivers. The effect will continue to affect both Control and Sensing logic. At the end, almost the whole software has to be rewritten in order to cope with the evolution of the SEP as Figure 3.

Figure 3 Ripple Effect when there is SEP change

The hardware configuration of HAN devices brings

further complication of software architecture and also increases the difficulty for migrating from one system to the others.

Usually, RF chipset suppliers provide two types of ZigBee based chipsets. One is network coprocessor (CoP)

that functions as a transceiver together with basic stacks. SE HAN devices developers have to develop another microcontroller to work with the CoP. The other type of RF chipset is system on chip (SoC) that consists of both RF transceiver and also a built-in microcontroller. HAN devices developers can just use the SoC alone to build the whole system but can also use the SoC together with an external microcontroller to build a more sophisticated system. Figure

4 shows all three common configurations.

Figure 4 Three common hardware configurations of HAN devices implementation

Usually, HAN devices developers will develop

different HAN devices with one of the hardware configurations described. The whole application level is tightly coupled with different hardware configuration and the software is difficult to reuse and migrate to other hardware configuration.

As the hardware configurations of microcontroller and SoC are very different, the implementation of profile handler and hardware drivers are usually tightly coupled to the related hardware based on traditional development method. The software architectures for these three configurations are very different. For example, for hardware configuration 1, both network and infrastructure levels are stored in CoP and the profile framework together with the profile handler and hardware drivers are implemented in microcontroller. They are communicating through inter-microcontroller communication, such as SPI and UART. For hardware configuration 2, all these three layers together with profile handler and hardware drivers are implemented in the SoC. The software architecture for hardware configuration 3 will be more complicated as hardware handling may be shared by two microcontrollers. This causes the software be difficult migrating from one of the hardware configuration to the other if the architecture is not well designed to cope with reuse and ease migration.

The maturity of SEP 2.0 is a driving force to push HAN devices developers to upgrade their devices with more sophisticated and powerful hardware. HAN devices developers can also moving from one of the simple configuration to a more complicated but capable hardware configuration, such as from hardware configuration 1 to 3. However, if based on the traditional architecture design, the work required for such migration is significant. Hence, it is highly desired in the industry to come up with a scalable and reusable architecture that can help to speed up the software development to cope with the rapid change of SEP definition.

2

1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

In order to develop the architecture for Smart Energy HAN devices, we have to consider both the characteristics of smart energy application and embedded software. Here listed the key considerations for such architecture:

For SEP implementation, there are three factors to consider for designing the architecture:

• Fast evolution of the SEP • Event driven for demand response and load control • Expendable to cope with all different hardware

configurations For embedded system, all the unique characteristics of

embedded software also needed to consider in the architectural design.

• Real-time characteristic • Heterogeneity characteristic • Multi-processors expansion • Non-function requirement, such as limited resources

and processing power

III. EMBEDDED SOFTWARE ARCHITECTURE REVIEW Component based approach facilitates reuse and allowing

a better return on intellectual property investments [5]. There are also a large number of component based reuse model proposed and discussed [6-9]. However, just based on component-based approaches, it may not well suitable for the fast evolving SEP definition. Software architecture is believed can help to tackling this challenge and facilitate reuse [10, 11]. According to IEEE definition, software architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution [12]. Hence, the fast evolution of the SEP definition is best address through the right architecture design. In [11], software architecture definition is further extended to address non-functional requirements that are the key characteristics of embedded system.

Layered architecture will help to align components for reusability [13, 14]. There are also many literatures revealed the benefit of layered architecture applying to the embedded software development [15-18]. However, as discussed before, for SEP evolution, it is not just affecting the profile and clusters definition but also need to have higher capable hardware to support. In such case, if we simply apply layered architecture, the evolution of SEP will also affect every layer and inducing ripple to other levels. This will affect the reusability of the software greatly. Furthermore, for SE HAN devices, we also have to consider the scalability of the architecture in order to cope with both functional expansion of individual devices and also SEP evolution. Software Stability Model (SSM) [4] caters most of the requirements so we adopt it as the basis to develop the reusable architecture for SE HAN devices.

Software Stability Model [4, 19] classifies the system architecture into three layers: Enduring Business Themes (EBT), Business Objects (BO) and Industrial Object (IO). EBT consists of all core conceptual components that will not change both internally and externally over time and domain neutral. BOs are objects that are internally stable but externally adaptable. IOs are tangible components of the software system that can change both internally and externally over time [4].

Recently, SSM was further applying to domain pattern identification [20] and real time computing systems [21]. However, there is no discussion of the application of SSM to

embedded system for handling the heterogeneity, multi-processors expansion and limited resources issue. This paper will further discuss how to handle these three characteristics of the embedded system of HAN devices while applying SSM.

IV. STABLE SOFTWARE ARCHITECTURE FOR HAN DEVICES

A. Stability of the Architecture Even there are four type of clusters related to SE HAN

devices, namely, DRLC, Price, Message and Simple Metering. There are only two important conceptual functions that enduring for the life of the SE HAN devices: 1) Messaging and 2) Responding to Demand. All SE HAN devices have to perform at least one of them. The “Messaging” function shows to end user their metering information including pricing and alerting messages from utility companies. The “Responding to Demand” function will allow the utility company controls directly the energy usage equipment, such as HVAC system, heater, and heavy duty appliances through SE HAN devices. Hence, we place these two enduring conceptual functions in EBT. For real time control system, Monitoring and Controlling are also two enduring conceptual functions [21]. Hence, the EBT of the architecture we proposed consists of the following key components:

• Responding to Demand • Messaging • Controlling and • Monitoring

As all the SE clusters definition will change over time, they all belong to IO. With the same argument, all hardware and hardware related driver can change and shall belong to IO.

For BO, we introduced the “Interpreted Clusters” as an internal stable component that can be reused for all future development. The “Interpreted Clusters” will connect the evolving Clusters through hook that is a simple direct interpretation program. The “Interpreted Clusters” implement all the basic functions of Clusters but with fixed interfaces. For hardware drivers, we introduce the abstract components “Resources” that hook to them. The “Resources” components consist of all functions or methods that relate to different hardware drivers but only in logical way. For example, EEPROM page read write will be handled here but the final hardware related methods or functions will be handled by “Hardware Drivers”. Another important stable component “Scheduler” is introduced as SE HAN is an event driven device. “Scheduler” will manage all timing related matter of demands from clusters or the control logic from the device itself.

Using DRLC device as an example, with SSM, the architecture of DRLC handled devices is shown on Figure 5.

When there is any change in SEP clusters structure, even such change causes the hardware changes; the only change in software will be the IO related components and the hook that doing the interpretation of newly developed DRLC clusters. The core architecture of the software, the components of both EBT and BO, will remain stable and can be reused.

3

1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

Figure 5 SSM for DRLC Handling Architecture

B. Scalability of the Architecture Such architecture is also easy to expand to cope with additional functions. As HAN devices can optionally implement different logic for energy saving based on Price level. Let us discuss an example for such implementation. If the HAN devices would like to react to the price change and control the related equipment, the architecture can extend as Figure 6. The added components have very little effect on existing developed components.

The “Price Reactor” and “Interpreted Price” components are also internally stable components and can be reused. The “Price Usage Table” is defined as a logic table for defining the Price to Electricity Usage relationship that can easily be modified and changed over time.

C. Multi-controller handling architecture There are two unique characteristics of embedded system

have to be addressed especially for SE HAN devices development. They are the limited resources of a single microcontroller and the other is the heterogeneity characteristics of the embedded system [22].

The SoC usually has very limited resource, at most just couple of hundreds Kilo Bytes. Furthermore, with the

limited input/output (I/O), it is impossible to handle some heterogeneity resource that is not available inside it, such as, A/D port for environmental sensing. Hence multiple microcontroller implementations are commonly found in HAN devices industry.

Figure 6 SSM of DRLC + Pricing Handling Architecture

There is no discussion of applying SSM to multiple

microcontrollers as SSM was initiated to target for general-purpose system. To deal with this limitation, we introduced two components in the architecture in order to make it as an expandable architecture for multiple microcontrollers design.

The first component we introduced to supplement the Scheduler is a Scheduler Synchronizer so that it will work with other microcontroller in synchronization.

The second component we proposed is the Resource Agent that helps to allocate resource to either internal or external of the microcontroller [23]. Both Scheduler Synchronizer and Resources Agent will use the Inter-controller Link to communicate with other microcontroller.

D. Full architecture for SE HAN devices The full architecture is developed with the consideration

4

1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

of all four key EBTs: Messaging, Responding to Demand, Controlling and Monitoring as Figure 7.

Messaging components will handle all messages related functions. There are three clusters relating to message display: Message Clusters, Pricing Clusters and Simple Meter Clusters.

It is obvious that DRLC clusters directly related to “Responding to Demand” component. However, both Pricing and Simple Meter Clusters are also indirectly related to “Responding to Demand” component. As SE HAN devices can optionally implement different logic for energy saving based on Price levels or energy consumption levels. Therefore, both “Price Reactor” and “Energy Consumption Reactors” will also responding to the indirect demand through price and energy consumption measurement.

As discussed before, this architecture is fully scalable. For any particular HAN device, it is only necessary to implement part of the functions. Therefore, only part of the architecture will be used for any particular device. SE HAN device developers can also gradually establish the code of one conceptual component of EBT and related BO and IO first. For example the implementation of In-Home Display (IHD), only the Messaging component and all related Interpreted Clusters needed to be implemented. All other three EBTs and those related components can be ignored. After the development of the IHD, if there is a Programmable Controlled Thermostat (PCT) with Messaging functions, those components developed for IHD

can be reused except the hardware drivers of the IO. If there is any change on clusters definition, the only code needed to be rewritten is the Interpret hook that connecting the Interpreted Clusters to the evolving clusters.

V. CASE STUDY Let us illustrate the scalability and expandability of

multiple microcontrollers of this architecture with a case study.

A DRLC device was initially implemented with the architecture as Figure 5. Such device was requested to expand to incorporate with Messaging function of showing Messages from utility company. However, there are two issues with such added function. The first one is the limitation of program memory of the SoC used initially for the DRLC. The second issue is no display hardware implemented in the original design.

With traditional approach, the whole architecture has to be developed for allocating the resources to different controllers. With the architecture proposed in this paper, those components of EBT and BO implemented on SoC can be directly reused for a newly developed microcontroller. The only newly developed components will be the hardware drivers of the microcontroller. The architectures of the implementation are shown in Figure 8. Basically, both SoC and Microcontroller architectures are collapsed from the full architecture of Figure 7. Once the Schedule Synchronizer

5

1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556576061

and Resources Agent are developed, it can also be reused for different microcontrollers as they are internally stable components. The Inter-controller Link may be changed over time as it depends on the communication hardware used.

VI. CONCLUSION Smart Energy HAN Devices are important components in

smart grid network. They either transfer the important messages or energy related information from utility company or smart meter to end user or directly controlling energy consuming equipment, such as Air Conditioner, Heater. As Smart Grid is a newly developed technology and the key protocol Smart Energy Profile keep evolving during this immature stage. This caused the industry invest a great deal of resources in handling the changing profile together with the hardware changes. This paper proposed the software architecture based on SSM with a novelty expansion by introducing Schedule Synchronizer and Resources Agent to cope with both single and multiple microcontroller scenarios. With the proposed architecture, the core components of EBT and BO are stable and can be reused with the evolution of SEP together with enhancement of hardware. The proposed architecture also considered all characteristics of both SEP and embedded software.

Although this paper focused the discussion of the applications of the architecture to all three hardware configurations commonly used for SE HAN devices development, with the scalability property it can be easily expanded to use for other hardware configuration during the evolution of the SEP.

SE HAN devices are also price sensitive as the final deployment is talking about millions of units. The advancement of the microcontroller development always improves its capability while pushing cost down. With the proposed architecture, the reusability of all stable components of EBT and BO will help to reduce the time and resource required to migrate the software from existing system to a more sophisticated microcontroller over time.

VII. REFERENCES BIOGRAPHIES

[1] ZigBee Alliance. ZigBee smart energy profile specification version 2.0 draft. [Online]. 2011. [2] I. Crnkovic, "Component-based approach for embedded systems," in Proc. 9th Int'l Workshop on Component-Oriented Programming, Oslo, 2004. [3] B. Guo, X. Chen and D. Li, "Analysis of the technical requirements for the smart energy," in Proc. Int'l Conf. Advances in Energy Eng. 2010, pp. 1-4. [4] M. E. Fayad, H. S. Hamza and H. A. Sanchez, "Towards scalable and adaptable software architectures," in Proc. IEEE Int'l Conf. Information Reuse and Integration, 2005, pp. 102-107. [5] C. R. Aguayo Gonzalez, C. B. Dietrich and J. H. Reed, "Understanding the software communications architecture," IEEE Communications Magazine, vol. 47, pp. 50-57, 2009. [6] T. Kanstren, "A study on design for testability in component-based embedded software," in Proc. 6th Int'l Conf. Software Eng. Research, Management and Applications, 2008, pp. 31-38. [7] J. Kwon and S. Hailes, "A lightweight, component-based approach to engineering reconfigurable embedded real-time control software," in Proc. 9th IEEE Symposium on Parallel and Distributed Processing with Applications Workshops, 2011, pp. 361-366. [8] L. Wang, "Component-based performance-sensitive real-time embedded software," IEEE Aerospace and Electronic Systems Magazine, vol. 23, pp. 28-34, 2008. [9] C. Bunse, H. G. Gross and C. Peper, "Applying a model-based approach for embedded system development," in Proc. 33rd EUROMICRO Conf. on Software Eng. and Advanced Applications, 2007, pp. 121-128.

[10] S. Malek, M. Mikic-Rakic and N. Medvidovic, "A style-aware architectural middleware for resource-constrained, distributed systems," IEEE Trans. Software Eng., vol. 31, pp. 256-272, 2005. [11] I. Gorton, "Understanding software architecture," in Essential Software Architecture, I. Gorton, Ed. Springer Berlin Heidelberg, 2006, pp. 1-15. [12] IEEE, "ISO/IEC Standard for Systems and Software Engineering - Recommended Practice for Architectural Description of Software-Intensive Systems," ISO/IEC 42010 IEEE Std 1471-2000 First Edition, pp. 1-24, 2007. [13] J. Savolainen and V. Myllarniemi, "Layered architecture revisited — comparison of research and practice," in Joint Working IEEE/IFIP Conf. Software Arch. & European Conf. Software Arch. 2009, pp. 317-320. [14] M. Paris, "Reuse-based layering: A strategy for architectural frameworks for learning technologies," in Proc. IEEE Int'l Conf. Advanced Learning Technologies, 2004, pp. 455-459. [15] X. Luan, J. Ying and M. Wu, "A heterogeneous evolutional architecture for embedded software," in Proc. 5th Int'l Conf. Computer and Information Technology, 2005, pp. 901-905. [16] A. Bianco, J. M. Finochietto, G. Galante, M. Mellia, D. Mazzucchi and F. Neri, "NXG05-3: Scalable layer-2/Layer-3 multistage switching architectures for software routers," in Proc. IEEE Global Telecom. Conf. 2006, pp. 1-5. [17] Y. Bai and H. Chen, "Design and implementation of layer architecture software modules for LCD TV systems," IEEE Trans. Consumer Electronics, vol. 51, pp. 725-730, 2005. [18] J. Lin, "An auto-adaptable video streaming system for on-line monitoring of remote experiment using two-layer software architecture," in Proc. IEEE Int'l Conf. Virtual Environments, Human-Computer Interfaces and Measurements Sys. 2009, pp. 63-67. [19] M. Fayad and S. Wu, "Merging multiple conventional models in one stable model," Commun ACM, vol. 45, pp. 102-106, September, 2002. [20] A. M. Mahdy, H. S. Hamza, M. E. Fayad and M. Cline, "Identifying domain patterns using software stability," in Proc. IEEE Int'l Conf. Information Reuse and Integration, 2004, pp. 18-23. [21] E. R. Naganathan and X. P. Eugene, "Software stability model (SSM) for building reliable real time computing systems," in Proc. 3rd IEEE Int'l Conf. Secure Soft. Integration and Reliability Improvement, 2009, pp. 431-435. [22] E. A. Lee, "Embedded Software," Advances in Computers, vol. 56, pp. 56-97, 2002. [23] M. Sojka, P. Pisa, D. Faggioli, T. Cucinotta, F. Checconi, Z. Hanzalek and G. Lipari, "Modular software architecture for flexible reservation mechanisms on heterogeneous resources," J. Syst. Archit., vol. 57, pp. 366, 2011. Waileung Ha (M’06) received the MSc(Eng) degree in engineering from University of Hong Kong and MSc degree in Electronic System Design from City University of Hong Kong. He is the Executive Vice President – Technology of Computime Ltd. A public listed company in Hong Kong focused on electronic control devices design and manufacturing. His team is focus on latest Smart Energy related product development. He is interested in the field of embedded software architecture, embedded software modularity design and reuse. Hongyi Sun (M’93) received Bachelor degree in Computer Science from Harbin University of Science and Technology, Master degree in Engineering Management from Harbin Institute of Technology (HIT), both in China, and Ph.D. in Technology Management from Aalborg University in Denmark. Dr Sun is currently an Associate Professor at the Department of Systems Engineering and Engineering Management, City University of Hong Kong. His teaching and research areas include management of technological innovation, new product development, manufacturing/operations strategy, and quality management. Dr Sun has published 100 papers in refereed international journals and conferences.

6