下载文档原格式
Ice中间件研究简介Ice 是一种面向对象的中间件平台。
从根本上说，这意味着Ice为构建面向对象的客户－服务器应用提供了工具、API 和库支持。
Ice 应用适合在异构环境中使用：客户和服务器可以用不同的编程语言编写，可以运行在不同的操作系统和机器架构上，并且可以使用多种网络技术进行通信。
无论部署环境如何，这些应用的源码都是可移植的。
安装windowsWindows平台安装比较简单，下载安装文件然后安装即可。
Windows安装文件已带有demo。
Linux1.下载Ice-3.4.1-rhel5-i386-rpm.tar.gz2.安装文件放到linux任意目录，打开linux终端3.解压文件#tar xzvf Ice-3.4.1-rhel5-i386-rpm.tar.gz4.安装必要的rpm#rpm -ivh ice-3.4.1-1.rhel5.noarch.rpm#rpm -ivh db48-4.8.30-1ice.rhel5#rpm -ivh ice-libs-3.4.1-1.rhel5#rpm -ivh ice-servers-3.4.1-1.rhel5#rpm -ivh ice-utils-3.4.1-1.rhel55.根据需要安装宿主语言支持，本例为java#rpm -ivh db48-java-4.8.30-1ice.rhel5#rpm -ivh ice-java-3.4.1-1.rhel5#rpm -ivh ice-java-devel-3.4.1-1.rhel5安装完毕，如需要demo,需要下载Ice-3.4.1-demos.tar.gzIce服务Ice 核心为分布式应用开发提供了一个完善的客户－服务器平台。
但现实应用需要的常常不止是远程通信能力：你通常还需要拥有这样的能力：随需启动服务器、把代理分发给客户、分发异步事件、配置你的应用、分发应用补丁，等等。
在Ice 中有一些服务，能够提供上述特性及其他一些特性。
ICE中间件研究笔记22.6 ICE网格计算IceGrid用于支持分布式网络服务应用，一个IceGrid域由一个注册表(Registry)和任何数目的节点(Node)构成。
注册表(Registry)和节点(Node)一起合作管理一些信息以及包含一些应用(Application)的服务进程。
每项应用(Application)被指定在特定节点上的服务。
这个注册表(Registry)持久记录了这些信息，而节点(Node)负责启动和监测其指定的服务器进程。
对于一个典型的配置，一个节点(Node)运行在一台计算机(称之为Ice服务器主机)。
注册表(Registry)并不消耗很多处理器时间，所以它常常是和一个节点(Node)运行在同一台计算机上的，注册表(Registry)还可以和一个节点(Node)可以运行在同一进程中.如果需要容错，注册表(Registry)还可以用主从式的设计支持复制(Replication)。
注册表(Registry)的主要责任，是解决作为Ice定位服务的间接代理问题，当客户端第一次尝试使用一种间接代理，客户端Ice run time首先连接注册表(registry)，注册表将间接代理的符号信息转化为直接代理的endpoint，然后客户端和直接代理建立一个连接。
通过适配器复制，同名适配器可以分布在多个节点上，间接代理可以映射到多个节点上的直接代理，在运行时由注册表服务根据负载均衡自动选择一个直接代理给客户端。
使用间接代理时，客户端可以用以下方式直接获取服务对象代理：MyProxy=theObject@theAdapter//对象@适配器更简单一点的话可以用以下方式MyProxy=theObject//对象2.6.1分布式部署在部署IceGrid分布式服务时，需要启动注册表服务(icegridregistry)，并配置注册表服务地址端口、通信协议和注册信息保存的目录地址(ICE的注册信息保存为BerkeleyDB的数据库文件)：IceGrid.Registry.Client.Endpoints=tcp-p 4061IceGrid.Registry.Data=/opt/ripper/registry在服务器节点中和客户端都需要配置注册表服务的地址端口和通信协议：Ice.Default.Locator=IceGrid/Locator：tcp-h 172.0.0.1-p 4061然后分别启动注册表服务(icegridregistry)和节点服务(icegridnode).ICE提供了部署工具icegridadmin,这个icegridadmin工具也需要定义Ice.Default.Locator属性.接下需要编写应用部署文件，应用部署文件以XML方式保存。
国家能源ice操作手册一、引言国家能源ICE（Internet Control Energy）系统是一个集能源管理、控制和优化于一体的先进系统。
本操作手册旨在为操作人员提供全面、详细的操作指南，确保系统稳定、高效地运行。
二、系统概述国家能源ICE系统采用先进的互联网技术，实现对能源设备的远程监控、控制和优化。
系统具备实时数据采集、数据分析、故障诊断、远程控制等功能，为企业提供全面的能源管理解决方案。
三、操作流程1.登录系统操作人员使用个人账号登录系统，确保账号与权限相符。
账号分为管理员、操作员和访客三种类型，权限各不相同。
2.数据采集与监控系统自动采集能源设备数据，实时展示设备运行状态、能耗情况等信息。
操作人员可对设备进行实时监控，确保设备正常运行。
3.数据分析与优化系统对采集的数据进行深入分析，为企业提供能源消耗报告、设备效率分析等数据支持。
操作人员可根据报告进行设备优化调整，降低能源消耗。
4.故障诊断与处理当设备出现故障时，系统自动报警并提示故障原因。
操作人员根据提示进行处理，确保设备及时恢复正常运行。
5.远程控制与调整操作人员可根据实际需求，对能源设备进行远程控制和调整。
通过系统界面，可实现对设备的开关机、参数设置等操作。
四、注意事项1.确保系统环境安全稳定，避免因外部因素导致系统崩溃或数据丢失。
2.定期对系统进行维护和升级，确保系统功能不断完善，满足企业需求。
3.严格遵守操作规程，避免因误操作导致设备损坏或数据异常。
4.定期备份数据，确保数据安全可靠，防止意外情况发生。
5.在处理故障时，应先切断设备电源，确保人员安全。
然后根据故障提示进行处理，切勿盲目操作。
6.保持与设备供应商的沟通与联系，及时了解产品更新和技术支持情况。
7.定期对操作人员进行培训和考核，提高操作技能和安全意识。
8.建立完善的应急预案和故障处理机制，确保在突发情况下能够迅速响应并解决问题。
ICE中间件技术详细教程一、ICE中间件概述ICE中间件是一种基于网络的通信框架，它允许不同机器上的应用程序进行通信，并提供了高性能和可扩展性。
ICE基于面向对象的编程模型，将通信对象抽象为接口，并通过接口定义通信协议，从而隐藏了底层通信细节，使开发者可以专注于业务逻辑的实现。
ICE中间件支持多种编程语言，包括C++, Java, Python等，这使得开发者可以使用自己熟悉的编程语言来开发分布式应用程序。
ICE中间件还提供了丰富的工具和库，以便开发者可以更加方便地开发和调试应用程序。
二、ICE中间件的安装和配置安装完成后，需要配置ICE的环境变量。
在Windows系统下，可以在系统环境变量中添加ICE_HOME变量，并将ICE的安装路径作为其值。
在Linux系统下，可以在.bashrc文件中添加exportICE_HOME=/path/to/ice命令。
完成配置后，重新启动终端使其生效。
三、ICE中间件的基本使用在ICE中，应用程序之间的通信是通过接口进行的。
首先，需要定义接口，并使用Slice语言编写其接口规范。
Slice语言是一种专门为ICE设计的领域特定语言，用于定义接口的数据类型和方法。
例如，以下是一个简单的Slice接口定义：```slicemodule MyModuleinterface MyInterfacevoid sayHello(;};};```接口定义完成后，可以使用Slice编译器将其编译为不同语言的接口代码。
例如，可以使用slice2java命令将上述接口编译为Java代码。
接口代码生成后，可以在应用程序中使用该接口。
首先，需要创建ICE运行时环境并初始化。
然后，可以通过接口代理创建一个远程对象。
远程对象代表了另一个应用程序中的接口对象，可以通过它来调用远程接口的方法。
以下是一个简单的Java示例代码：```javaimport MyModule.*;public class Mainpublic static void main(String[] args)MyInterfacePrx myInterface =MyInterfacePrx.checkedCast(proxy);if (myInterface == null)throw new Error("Invalid proxy");}myInterface.sayHello(;}}```上述代码中，通过调用stringToProxy方法创建一个接口代理。
ICE简单介绍及使用示例1、ICE是什么？ICE是ZEROC的开源通信协议产品，它的全称是：The Internet Communications Engine，翻译为中文是互联网通信引擎，是一个面向对象的中间件，使我们能够以最小的代价构建分布式应用程序。
ICE使我们专注于应用逻辑的开发，它来处理所有底层的网络接口编程，这样我们就不用去考虑这样的细节：打开网络连接、网络数据传输的序列化与反序列化、连接失败的尝试次数等。
2、为什么会有ICE？ICE是分布式应用的一种比较好的解决方案，虽然现在也有一些比较流行的分布式应用解决方案，如微软的.NET（以及原来的DCOM）、CORBA及WEB SERVICE 等，但是这些面向对象的中间件都存在一些不足：.NET是微软产品，只面向WINDOWS系统，而实际的情况是在当前的网络环境下，不同的计算机会运行不同的系统，如LINUX上面就不可能使用.NET；CORBA虽然在统一标准方面做了很多的工作，但是不同的供应商实现之间还是缺乏互操作性，并且目前还没有一家供应商可以针对所有的异种环境提供所有的实现支持，且CORBA的实现比较复杂，学习及实施的成本都会比较高；WEB SERVICE最要命的缺点就是他的性能问题，对于要求比较高的行业是很少会考虑WEB SERVICE的。
ICE的产生就是源于.NET、CORBA及WEB SERVICE这些中间件的不足，它可以支持不同的系统，如WINDOWS、LINUX等，也可以支持在多种开发语言上使用，如C++、C、JAVA、RUBY、PYTHON、VB等，服务端可以是上面提到的任何一种语言实现的，客户端也可以根据自己的实际情况选择不同的语言实现，如服务端采用C语言实现，而客户端采用JAVA语言实现，底层的通讯逻辑通过ICE的封装实现，我们只需要关注业务逻辑。
3、ICE是如何工作的？Ice 是一种面向对象的中间件平台，这意味着 Ice为构建面向对象的客户－服务器应用提供了工具、API 和库支持。
一IEC框架介绍Ice 是一种面向对象的中间件平台。
从根本上说，这意味着Ice 为构建面向对象的客户－服务器应用提供了工具、API和库支持。
Ice 应用适合在异种环境中使用：客户和服务器可以用不同的编程语言编写，可以运行在不同的操作系统和机器架构上，并且可以使用多种网络技术进行通信。
无论部署环境如何，这些应用的源码都是可移植的。
什么是ICE?ICE(internet communications engine)是适用于异种环境的面向对象中间件平台。
那么什么是中间件呢?比较流行的定义是:中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源。
中间件位于客户机/服务器的操作系统之上，管理计算资源和网络通讯。
从中间件的定义可以看出，中间件是一类软件，而非一种软件；中间件不仅仅实现互连，还要实现应用之间的互操作；中间件是基于分布式处理的软件，定义中特别强调了其网络通讯功能.2.ICE的一些概念服务器/客户端(server/client):这个的定义与一般的定义相同,主动的一方被认为是clientICE对象:跟OOP中的对象类似,不同之处在于,在分布式的环境中,同一个ICE对象在不同的地址空间中都可能存在着.ICE对象也提供了一组接口(facets).ICE对象还有一个特殊的接口:主接口.代理(proxies):是ICE对象引用,代理是在客户地址空间,客户对ICE对象的操作就是通过代理来进行的.代理封装了完成:ICE对象的寻址(包括服务器的寻址),激活ICE对象,传入参数,等待执行并返回执行结果servant:在服务器上的执行体,ICE对象对服务器的操作就是通过调用servant."最多一次"原则:一次对目的的访问,只会执行一次(并不排除出错重试)ICE的5个服务Summary这里介绍了ICE的五个服务Ice为分布式开发提供了技术完善的客户-服务平台。
Off-the-shelf Embedded Middleware Solution for UA Vs HW-SW Platform DevelopmentJ.Barba,F.J.Villanueva,M.J.Abaldea,D.Villa,O.Acena and J.Carlos L´o pezARCO Research Group.School of Computer Science.University of Castilla la Mancha.Ciudad Real(Spain)Email:jesus.barba@uclm.esAbstract—In this paper a Commercial-off-the-Self(COTS) platform for Unmanned Aerial Vehicles(UA V)is presented.The goal of this work is to provide the industry with aflexible and efficient solution to smooth the integration and heterogeneous de-velopment challenges in this scenario.On one hand,the proposed platform enables transparent and efficient interaction with the control station implemented in ZeroC Ice.On the other hand, the proposed approach abstracts both embedded and desktop software developers from the platform details.A customized hardware-software layer assures a high-level,efficient reliable communication while a complete tool-chain automatizes the generation of application specific code,reducing the development time.Index Terms—Middleware;UA V;ZeroC-Ice;Hw-Sw Integra-tion;I.I NTRODUCTIONUnmanned Aerial Vehicles(UA V)are extending its appli-cationfield from military scenarios to civil applications[1]. The domain of civil UA V applications is dominated by low-cost vehicles which are devoted to specific tasks like smart agriculture[2],smart city[3],rescue tasks[4],etc.These type of UA Vs usually rely on an embedded board with key features such as low-weight and low power consumption so as to extend UA V operation lifetime.One of the most promising approaches for next-generation UA V on-board platforms is the use of hybrid systems where micro-controller and reconfigurable logic come together,for example.These type of boards areflexible enough to support a wide range of applicationfields,ranging from vision-based applications-where FPGAs(Field-Programmable Gate Array)can apply their computing power to avoid sending raw multimedia data through the wireless link-to sensor-based applications,cryptography,etc.In this paper an object-oriented software platform for UA V application development is introduced.The main contributions of our work are:•Seamless integration of application specific hardware and software components which eases the development of hybrid systems.This is achieved because of the use of a common,high-level model which abstracts our platform functionality(either hardware or software)as a series of objects.•Reduction of the development time.The developer is provided with a toolchain(interface definition languageand interface compiler)which automatizes the generation of the integration infrastructure.•Optimal and efficient implementation of the middleware engine.Traditional distributed object-oriented frame-works require excessive resources for most of the UA V HW platforms.As it will be shown later,the footprint of the core components is minimized in order tofit in the smallest embedded boards.The remainder of this article is organized as follows. Next section describes the state of art in UA V application development and also establishes a set of requirements for a software platform in this applicationfield.Section III and IV thoroughly describes the proposed architecture along with in-terface specification and development process.In section V the communication engine called IceC is described.Finally,some of the most relevant quantitative and qualitative aspects of the prototype are described,along with the main conclusions.II.P REVIOUS WORKSThere are a great market opportunity and a lot of companies are setting up their own platforms to support UA V applications. As consequence of this great expansion of these type of vehicles,there is a lack of embedded standard computing platforms for UA V app development.Already in2001,Boeing realized the need of a middleware for this type of vehicles,in[5]Boeing proposes an Open Control Platform(OCP)in order to deal with UA V control tasks.OCP uses ACE(Adaptive Communication Environment) an TAO(an ACE ORB)forflight control tasks modeling following the CORBA model.A similar approach is followed in[6].We agree in this object-oriented vision but we extend to HW components in order to deal with HW implemented algorithms(e.g a vision-processing VHDL algorithm)like any other software object in a transparent way.The component model also has been applied to UA V market. In[7]a C++component-based middleware is developed providing with components related mainly withflight mission. Again there is a lack of a toolchain in order to automate the work in application specific components or any reference to HW component integration.The service-oriented middleware(SOM)has been proposed for UA V development,in[8]an exhaustive listing of needed services for UA V application development is elaborated.In2016 30th International Conference on Advanced Information Networking and Applications Workshopsspite of the well-know set of benefits of SOM(quite similar to object-oriented middleware)in terms of software reuse and time-to-market reduction,there is no specific proposal in this work about toolchain or specific interfaces so it is about a top-level design exercise.Data Distribution Service(DDS)from Object Management Group(OMG)[9]is used in the UA Vfield.When commu-nications or interaction between components are stateless is a good approach however when we have to model more complex interactions with state,this approach doesn’tfit with this type of applications.Specific middlewares have been developed for specific tasks (coordination functions[10],avionics subsystems[11],etc.), we are more devoted to design a generic middleware providing guidelines and tools for implement any type of functionality. None of the middlewares presented in this section have considered hybrid platforms or how to integrate HW com-ponents.We consider that there is a lack of solutions for this type of platforms which will play a key role in future UA V development.Our motivation is to build a middleware with:•Focus on hybrid platforms e.g.support hardware compo-nents and with transparent integration with the rest of the infrastructure.•A well-defined set of interfaces as guideline for develop-ers but providing theflexible reusability to adapt to each specific application.•A toolchain for automatic stub and skeleton generation to reduce the error-prone tasks of communication between components of the system(e.g UA V to ground station) and for interaction between SW and HW components.•Support for a efficient,commercial,legacy object-oriented middleware.In order to avoid reinventing the wheel effect,ZeroC Ice[12]is used as the starting point.The idea is to integrate the UA V control and communi-cation operations as another remote object in the system.Thus,the application running in the ground station,could access the services provided by the UA V in a transparent way,using the standard middleware mechanisms.How tofit all these requirements is a cross-layer challenge that it has not been addressed by previous works.III.UAV EMBEDDED PLATFORMAlthough many of the concepts and modules developed in our solution are platform agnostic,we set the Silica Xynergy board as the initial target for our solution.The reasons behind this election stem from lessons learned in a former versions of the UA V-platform and the evolution of the application re-quirements.Among this requirements,it is worth noting:cost-reduction,high-performance computing capabilities,a lower power budget to increaseflying time and a reduction of the overall weight of the solution.The Xynergy board is a heterogeneous platform which consists of a ARM Cortex-M3based STMicroelectronics controller and a low-cost FPGA from Xilinx.Due to a rich collection of dedicated and general I/O ports and built-in protocol interfaces,the Xynergy board is suitable for a widerange of applications.The FPGA fabric,a Spartan-6chip,is tightly coupled tothe ARM controller and is intended to hold Hw acceleratingblocks for computing intensive applications:video,digitalfiltering,cryptography,etc.FPGA technology provides a closeto custom hardware performance while being able to changetheir behavior through time.The development of applications and custom IP(IntellectualProperty)cores for the Xynergy board can be accomplishedby means of off-the-shelf tools freely available for multipleplatforms.A.Hardware supportIn this section,a description of the System-on-a-Chip de-ployed in the FPGA fabric is presented.The role of thereconfigurable device is multiple and comprises:•Interface between the DDR3RAM memory and the ARM controller which has no other mechanism to access thedata.•Accelerator of computing intensive functions by means of dedicated hardware.•Communication manager through a tailored hardwarecontroller.Fig.1.Architecture of the SoC deployed in the Spartan-6FPGA to support UA V embedded operations.Figure1graphically represents the main modules and the architecture of the hardware infrastructure which supports the above-mentioned functionality.The FSMC(Flexible Static Memory Controller)bridge implements a translator between the NOR/SRAM memory access protocol and the in-house internal bus protocol.The DDR3access has been implemented using the Xilinxs Multi Port Memory Controller core,configuring a minimum of two64-bit NPI ports depending on the number of cores that must have access to the RAM memory.The modem controller abstracts the access to the radio/wifimodem providing the same low-level operations for modem configuration and data transmission/reception(i.e.source and target MAC addresses,reset,baud-rate,memory map,etc.).The controller logic generates the corresponding AT com-mands to the network modem which is connected to the FPGA via a serial link.Finally,several IP cores can be instantiate whenever there were available resources in the FPGA.The functionality of each core may vary depending on the application,but the interface to the rest of the system remains unaltered.Low-level Hw-Sw interfacing:Communication between the software routines and the hardware components is imple-mented through a register-based interface and an interrupt mechanism.First,16memory words are assigned to the control and configuration registers for each processing IP core. Then,one or more memory blocks are assigned to the hard-ware cores.The number and the size of the blocks is defined by the application developer at design time.These memory blocks are used as input/output buffers where processing cores will write the data produced as the result of their operation or read the input data to be processed.Thus,it is established a producer-consumer integration pattern between the involved pairs in the communication process.The core bus wrapper decodes the addresses only within the control and configuration memory range.The content of the buffer memory can be accessed through the memory con-troller by the software routines but not through the individual core wrappers.Processing IPs are configured with the base addresses for their respective input/output buffers.The modem controller is an example of processing core. Configuration and control operations are done by means of regular write and read FSMC primitives.The FSMC bridge translates them into bus transactions and the register content is written or read.To send a data packet via the radio interface, the processor writes the content of the packet in RAM memory and then signals the core via a write operation that the packet is ready to be sent.The value to write indicates the modem controller the total size in bytes of the packet.Once the packet has been sent,the modem controller triggers an interrupt that wakes up a service routine responsible for checking error conditions.The receive operation for a data packet works conversely;first the modem controller signals the processor via an interrupt that a new packet is ready to be processed.The modem controller will have written the content of the packet in main memory,into the output buffer region assigned.The service routine will,finally,process the incoming packet.IV.S OFTWARE P LATFORMThe FPGA SoC,previously described,provides the UA V platform with hardware support for essential services such as external data storage and efficient radio packet management. Also,a placeholder for UA V hardware-accelerated functions and a protocol to access them and manage the movement of the data is available to developers.Based on a traditional register/memory mapped approach, a layered software infrastructure has been builtfirstly.The ultimate goal is to abstract all the communication details to the application level so that the embedded software developer will only have to deal with a set of high-level,automatically generated software routines.TheμC/OS-II operating system is at the basis of the software stack due to its low footprint,real-time and task model features.Infigure2,the reader canfind a representation of the whole software architecture for the middleware infrastructure. Focusing on the physical and transport layers,a customized FSMC driver has been coded in order to be compliant with the functional specification of the FSMC bridge;providing read and write primitives to access the DDR3and radio IPs. The radio driver is a standalone task in charge of transferring packet fragments from/to the DDR3memory and provides the next layer in the hierarchy(reliable network layer)with send and receive primitives.A send operation copies the packet fragment in the output buffer assigned to the radio controller and then signals the hardware to read it from memory and transfer to the radio interface.The radio driver manages the DDR3output buffer as a circular buffer using afixed size vector with all the necessary control information.A receive operation exposes a bit more complex behavior.Once the radio controller has finished writing a packet fragment in its DDR3input buffer,it raises/triggers an interrupt that is trapped by the radio driver. Depending on the nature of the packet,the radio driver must generate either the acknowledge messages(a new fragment has been received)or update the sending status of a packet(when an acknowledge has been received)which will be interpreted by the reliable network protocol layer later on.The network layer implements a reliable transmission pro-tocol since it is foreseen the use of restrictive wireless links for UA V to ground communication.The IEEE802.15.4RFC [13]has been considered for its use in the implementation of thefirst prototype of the UA V platform.This standard is suitable for low-cost and low-power wireless communications at the price of a low-bandwidth and small MTU(Maximum Transmission Unit).The overhead per fragment is small(just 4or5bytes)together with an acknowledge message that is generated by the receiver when a fragment is processed. AlthoughμC/OS-II comes with a implementation of the TCP/IP protocol stack,the requirements for the envisioned UA V platform open the door to the usage of a simpler and less resource demanding network protocol.So far,only point-to-point communication is required so it is only needed a reliable mechanism to fragment and reassemble application packets, which are likely not tofit into the physical MTU,leaving out all aspects regarding the routing of packets.A.IceC and application layersFrom the application’s point of view,the embedded software developer might make use of the reliable send and reliable receive primitives which are part of the API exposed by the reliable network layer.However,in order to ease the integra-tion and access of functionality from ground to UA V and vice verse,the UA V programmer is provided with the same system abstractions,work-flow and tools as the ones already availableFig. 2.Functional decomposition of the developed layered middleware infrastructure.in communication middlewares for networked systems.As a result,no special training nor skills are needed,leveraging previous background on distributed system application devel-opment.The embedded IceC1layer is the key element to make the magic happen.IceC is a lightweight implementation of IceP, the standard protocol of ZeroC Ice middleware2.Therefore, our UA V embedded platform is fully compatible with other ZeroC compliant systems.The only requirement is to reach an agreement on the definition of the services to be implemented.Since ZeroC Ice features an object-oriented model,the service declaration con-sists in a list of method and user-defined data type definitions. To this end,the developer uses a straightforward Interface Definition Language called Slice.As an example,Figure3shows a fragment of a simplified Slice definition of the communication interface used between the Ground Station(Station interface)and the UA V(Vehicle and HwProcessingEngine interface).When it comes to the specification of functionality which is going to be implemented as a hardware module,the interface specification must be tagged with the[”:hw”]meta-data directive.At this point,the Slice definition is processed by a home-made interface compiler which generates a set of functions providing the high-level,object-oriented stylish API to the application programmer.This functions or communication stubs(namely,proxies and skeletons)interact both with the client,server tasks and the IceC runtime so as to progressively translate the invocations into Ice Protocol messages to be sent through the radio interface.1IceC source code is available at:https:///arco_group/icec2 module Autopilot{enum TypeCode{boolT,intT,uintT,floatT,timevalT,byteseqT,stringT };[...]sequence<byte>ByteSeq;struct Param{ParamId id;TypeCode type;ByteSeq data;};sequence<Param>ParamSeq;[":hw"]interface HwProcessingEngine{void setParameterA(short value);void startProcessing(void);void getResult(ResultType*res);};interface Vehicle{bool isAlive(short sessionId);};interface Station{void vehicleState(Vehicle*uav,ParamSeq params);};};Fig.3.Example of Slice specification for IceC.V.D EEPLY EMBEDDED MIDDLEWAREThis section aims to provide an insight into the architecture and implementation details of the IceC engine.The IceC runtime layer is a minimal realization of the ZeroC Ice middleware,optimized for our UA V platform needs.In order to keep the compatibility with ZeroC Ice PC-based applications (the target platform for the Ground Station logic)and maintain the same philosophy and work-flow in the UA V side,several extensions and engineering works has had to be carried out. First and foremost,the development of the main architec-tural components of the commercial version following a low-footprint policy.The layer IceC comprises the core elements such as Communicator,Object Adapter,Servant Management, Connections and other helper functions.As a result,a complete static ad-hoc implementation of the principal ZeroC features has been obtained using ANSI C(C90standard)which allows:•An impressive reduction of the memory requirements.•Being supported by Keil compiler for ARM,the IDE used to develop the embedded software.•The resulting application to be potentially certificated when real-time restrictions apply.Second,the implementation of a transport specific config-urable plugin(PC and UA V)for the xbee connection:the xbee-at endpoint.This was necessary due to the following reasons:(a)Xbee is the choice for UA V-Ground Station radio link;and(b)is a necessary step in order to make it usable conventional ZeroC Ice vendor-libraries,tools and C++ bindings over GNU/Linux.And last but not least,the definition of a mapping of the ZeroC Ice Protocol for ANSI C language which did not exist before.This step comprises a set of rules and languages equivalences to transform Slice grammar and semantics into C structures.As a starting point,CORBA C language Map-ping Specification[14]and conventions used in the Ice C++mapping were taken into account.The result of all this work is a fully new language binding together with a interface compiler which generates the middleware stubs responsible for the marshalling and unmarshalling processes.As mentioned in the previous section,these communication stubs depend upon the Slice definition and they are produced specifically for an application in an automatic way.static void Autopilot_Vehicle_vehicleState(Autopilot_StationPrxPtr this,Autopilot_VehiclePrxPtr uav,Autopilot_ParamSeq params){Ptr_check(this);Ice_ObjectPrx_connect(this);Ice_OutputStreamPtr os=&(this->stream);/*request header*/Ice_OutputStream_writeBlob(os,Ice_header,sizeof(Ice_header));Ice_OutputStream_writeIdentity(os,this->identity);Ice_OutputStream_writeString(os,"vehicleState");[...]/*encapsulated params*/Ice_OutputStream_writeShort(os,sessionId);Ice_OutputStream_writePrx(os,uav);Autopilot_ParamSeq_writeToOutputStream(&(params),os);Ice_OutputStream_setMessageSize(os);Ice_ObjectPrx_send(this);}Fig.4.IceC generated code for a proxy.Figure4shows and example of the generated ANSI C code for the vehicleState method defined in Figure3,Section IV-A.This function is a proxy to the actual functionality implemented as a server in the Ground Station.The client task,which runs in the UA V,only needs to call the procedure as it is defined by its signature.By means of a set of utility functions implemented in the core of IceC middleware,the different parts of an IceP messages are generated and all the parameters serialized and stored in memory through the Ice OutputStream object.This object is a high-level abstraction of the memory write buffers, where the IceP messages are temporally held before they are sent.For each user data type defined in Slice(i.e.ParamSeq) a pair of functions are also generated which knows how to marshall and unmarshall such data type,according to the Slice(Autopilot ParamSeq writeToOutputStream)definition. Finally,the built message is sent out to the network using the reliable send primitive provided by the network layer. Client-server communication between UA V and ground station is performed by referring to remote objects.Coding in the UA V must be programmed in ANSI C(forμC-OSII) but for the ground station we have theflexibility to use any programming language supported by ZeroC Ice.Figure5shows the code for the server running at the UA V platform(upper half)and the code of the corresponding client executing on a standard PC written in Python(lower side).The objects that we can be identified are:(a)the communicator is part of the middleware core library and represents the object broker in ZeroC Ice parlance;(b)the PROXY and HWOBJECT void Autopilot_HwProcessingEngine_setParam(short value){ //servant goes here,registers acces through FSMC ifaceFSMC_write(...)[...]}void Autopilot_HwProcessingEngine_startProcessing(void){ //servant goes here,registers acces through FSMC ifaceFSMC_write(...)[...]}void appMainTask(void){XBeeInitTypeDef xbeeConf={XBEE_BD_115200,0x0000,0x0000};Ice_Communicator ic;Ice_ObjectAdapter adapter;Autopilot_HwProcessingEngine servant;xbeeInit(&xbeeConf);Ice_initialize(&ic);XBeeATEndpoint_init(&ic,"xbee-at");Ice_Communicator_createObjectAdapterWithEndpoints(&ic, "Adapter","xbee-at",&adapter);Ice_ObjectAdapter_activate(&adapter);Autopilot_HwProcessingEngine_init(&servant);Ice_ObjectAdapter_add(&adapter,(Ice_ObjectPtr)&servant,"hwengine1");Ice_Communicator_waitForShutdown(&ic);[...]}class Client(Ice.Application):def run(self,args):ic=municator()proxy=ic.stringToProxy(’hwengine1-o:xbee-at’)hwobject=Autopilot.HwProcessEnginePrx.uncheckCast(proxy) paramValue=0hwobject.setParameterA(paramValue)[...]Fig.5.UA V embedded server(ANSI C forμC-OSII)and Python client (ground station)are a local references of remote objects.In thefirst linesof the program,the necessary declarations are made and configuration and initialization of the XBee modem takes place as well.Following,the Ice Communicator is created,setting “xbee-at”as the endpoint to use3.Finally,the objects and references to objects needed by the application are got and the data structures containing the parameters to send arefilled out before invoking the SET P ARAMETER A remote method.In this scenario,the server requires of theI CE C OMMUNICATOR object(already explained),the ADAPTER and the SERVANT.The ADAPTER providesvisibility to the objects registered by the server,exposing their functionality to the rest of the network.A SERVANT is the piece of code which actually implements the functionalityof the interface.In this example,the reader can identify the interface Hw-ProcessingEngine which corresponds to an simplified exampleof a possible hardware object running on the FPGA platform. For each method declared in the Slicefile for such interface3XBee-AT endpoint implementation is available at https:///arco_group/xbee-at-endpoints/a function is generated which represents the API to be used from the ground station to,for example,setting up the algo-rithm parameters(i.e.setParameterA)or start the accelerating function.VI.R ESOURCE USAGEThe implementation of the UA V embedded platform de-scribed in the preceding sections has been carried out focusing in size optimizations.TABLE IS YNTHESIS RESULTS FOR THE FPGA S O C.Resource Total amountFlip Flops1537(8%)LUTs1728(18%)Slices772(33%)Table I summarizes the total amount of FPGA resources used by a basic configuration of the UA V SoC.It is only considered the FSMC bridge,the Memory Controller and the Radio IP.More than two thirds of the reconfigurable logic area is available for user application purposes.The results have been obtained with the ISE Design Suite11.3from Xilinx, targeting the XC6SLX16Spartan-6chip.The design runs at a clock frequency of100Mhz but the FSMC interface is limited by the Xynergy board to25Mhz which represents a serious bottleneck.TABLE IIS IZE IN BYTES OF THE DIFFERENT SOFTWARE LAYERS.Code Size Subsystem1116FSMC Driver1795Radio Driver1307Network Layer2622IceCConcerning the footprint in memory of the developed soft-ware stack,the results shown in table II confirm the high compactness of the solution with a total size of approximately just7KB.The generation of the object code has been done using the integrated compiler from theμVision IDE from Keil with the highest optimization level and disabling the debugging symbols.It has not been considered the inclusion of the memory overhead due to the IceC communication stubs.Since these pieces of generated software are application dependant,there is no impartial way to measure the impact in general terms. For the same reason,no timing analysis has been taken into account in this work.VII.C ONCLUSIONHW-SW hybrid boards are emerging platforms for UA V applications,however there is a lack of solutions/tools for developing on these type of platforms.In this paper,it has been dissected the architecture and im-plementation details of a tailored middleware infrastructure for hybrid embedded system.With extremely little resources,it is assured the compatibility with standard ZeroC Ice subsystems. No special tools,languages or design skills are required in order to integrate HW or SW components with our solution into an object-oriented networked system.The application use case,ground to UA V communication,introduces additional challenges which are faced using a combination of hardware and software.From an industrial point of view,apart from certification issues,our current efforts are devoted to extend the number of heterogeneous embedded platforms and legacy middlewares supported which can integrate in IceC.A CKNOWLEDGMENTThis work has been partly funded by the Spanish Ministry of Economy and Competitiveness under project REBECCA (TEC2014-58036-C4-1-R)and by the Regional Government of Castilla-La Mancha under project SAND(PEII-2014-046-P).R EFERENCES[1]AIA,“Unmanned aircraft systems:Perceptions&potential,”AerospaceIndustries Association,Tech.Rep.,2013.[2]J.Barcelo-Ordinas,J.Chanet et al.,“A survey of wireless sensortechnologies applied to precision agriculture,”in Precision agriculture 13,J.Stafford,Ed.Wageningen Academic Publishers,2013,pp.801–808.[3] F.Mohammed,A.Idries et al.,“Opportunities and challenges of usinguavs for dubai smart city,”in New Technologies,Mobility and Security (NTMS),20146th International Conference on,March2014,pp.1–4.[4]P.Doherty and P.Rudol,“A uav search and rescue scenario with humanbody detection and geolocalization,”in AI2007:Advances in Artificial Intelligence,ser.Lecture Notes in Computer Science,un and J.Thornton,Eds.Springer Berlin Heidelberg,2007,vol.4830,pp.1–13.[5]J.Paunicka,B.Mendel,and D.Corman,“The ocp-an open middlewaresolution for embedded systems,”in American Control Conference,2001.Proceedings of the2001,vol.5,June2001,pp.3445–3450vol.5. [6]J.Paunicka,D.Corman,and B.Mendel,“A corba-based middlewaresolution for uavs,”in Object-Oriented Real-Time Distributed Computing, 2001.ISORC-2001.Proceedings.Fourth IEEE International Sympo-sium on,May2001,pp.261–267.[7]J.Kwon and S.Hailes,“Mirea:Component-based middleware forreconfigurable,embedded control applications,”in Intelligent Control (ISIC),2010IEEE International Symposium on,Sept2010,pp.2385–2390.[8]P.Royo,J.Lpez et al.,“Service abstraction layer for uavflexibleapplication development,”in Proceedings of the46th AIAA Aerospace Sciences Meeting and Exhibit.Reno,Nevada(USA):AIAA,Jan2008.[9]G.Pardo-Castellote,“Omg data-distribution service:Architecturaloverview,”in Proceedings of the2003IEEE Conference on Military Communications-Volume I,COM’03.Washington,DC,USA: IEEE Computer Society,2003,pp.242–247.[10]M.Tortonesi, C.Stefanelli et al.,“Multiple-uav coordination andcommunications in tactical edge networks,”Communications Magazine, IEEE,vol.50,no.10,pp.48–55,October2012.[11] E.Santamaria,P.Royo et al.,“Increasing uav capabilities throughautopilot andflight plan abstraction,”in Digital Avionics Systems Confer-ence,2007.DASC’07.IEEE/AIAA26th,Oct2007,pp.5.B.5–1–5.B.5–10.[12]M.Henning,“A new approach to object-oriented middleware,”IEEEInternet Computing,vol.8,no.1,pp.66–75,2004.[13]G.Montenegro,N.Kushalnagar et al.,“RFC4944–transmission ofIPv6packets over IEEE802.15.4networks,”IETF RFC.[14]C Language Mapping Specification,Object Management Group,June1999.。
IceGrid应用配置手册V 2.1中诚信资讯科技有限公司目录1.概述 (3)1.1 配置目标 (3)1.2 实验环境 (3)1.3 局限 (3)2.配置过程 (3)2.1 服务器端配置 (3)2.1.1 主注册服务配置 (5)2.1.2 从注册服务配置 (7)2.1.3 应用部署配置 (10)2.1.4 节点配置 (13)2.2客户端配置 (14)3.结果验证 (14)3.1 程序方式 (14)3.2 工具方式 (14)4.高级应用配置 (20)4.1 集成IceBox (20)4.1.1 IceBox服务程序编写 (20)4.1.2 IceGrid集成IceBox服务 (21)4.1.3 测试验证 (25)4.2 集成IcePatch2 (27)1.概述1.1 配置目标本文档是描述Ice中间件中的IceGrid服务的应用配置，通过使用IceGrid服务来实现：1.服务器端服务分布式部署。
2.服务器端服务按需激活。
3.服务器端服务多节点负载均衡。
4.注册服务主/从热备（Master/Slaves）5.集成IceBox服务1.2 实验环境1.硬件：hp服务器，3台2.操作环境：Red Hat 53.服务器程序：ServerApp.jar4.说明：实际应用中，服务器节点可任意扩充、操作系统可被更换、服务器程序可用实际项目的服务程序替换，本文档所描述的配置方式具有通用性，适用但不局限于当前实验环境。
1.3 局限本文档不详细描述IceGrid服务的运行机制和实现原理，不详细介绍服务器端和客户端程序的实现，主要描述IceGrid服务应用的配置步骤、主要配置项及验证配置结果等。
2.配置过程2.1 服务器端配置配置步骤：1.创建主注册服务（Master）的配置文件config_master.grid，文件名称可以任意2.创建从注册服务（Slave）的配置文件 config_slave.grid，文件名称可以任意3.创建各节点服务的配置文件config.node，文件名称可以任意4.创建分布式应用配置文件app.xml，文件名称可以任意，但格式最好定义成xml5.运行Ice提供的工具，启动我们的分布式应用，主要有如下两个工具：icegridnode和icegridadmin。
