Mobile Edition
Print
Get the Mag
Weekly UpdatesWe wanted our platform to be open to as many sources of input as possible. These additional inputs could be from traffic sensors, wireless enabled street furniture, 'chipped' (RFID) street furniture, and on-street environmental sensors. The ability to cross-reference data from multiple diverse inputs greatly increases the value of the individual inputs leading to more valuable knowledge. For example, this kind of synthesised knowledge is being used in Barcelona where the city is already using inputs from traffic cameras, Bluetooth beacons, mobile phones, digital maps and a 'reasoning' engine to develop new traffic flow plans for the city. Simultaneously removing traffic from many streets and increasing the handling capacity of the remaining streets to remove traffic and noise from residential areas has resulted in quieter, calmer and safer cities.
To design the platform we first had to identify services that might be required by citizens. Historically, ICT projects have adopted a 'top down' approach. In contrast ICING was a 'bottom up' project, designed with the help of its final users. Co-design, by involving the final user in the initial design, tries to ensure that the final product (software, furniture, building) satisfies the real requirements of the final user. For ICING, the specification and design of the platform involved iterative consultations with likely end users. From the beginning of the project, ICING partners worked with local citizen groups, community associations, residents' associations, women's groups, sporting organisations and local shopkeeper associations. These groups identified the services that they felt would be useful to them and from which the city might benefit.
While the ICING project has piloted a relatively small number of ICING services, we have identified more than 30 others through this iterative consultation that could be offered--a number only limited by the imagination of citizens and cities. Some of these services include e-learning services, photography archives, reminder services, 'keep in touch' services, community news channels, community of interest channels and many others.
The partners also undertook a similar exercise within the three city councils where different operational units were asked to identify aspects of the services they provide. These included their role in overall city Council activities, their 'back office' procedures, their mechanisms for collecting various kinds of data and the usefulness of citizen inputs for their operation. Operational issues covered included the number of inputs that could be handled.
City councils have a wide variety of existing data systems in place. ICING did not intend to add a new layer of process or people to the city council's existing operation. The intention was that the ICING system would re-use existing systems and provide a channel to exploit existing information resources and to combine them with the new inputs expected from citizens.
ICING Technical Development
Having defined the service requirements from the point of view of citizens and cities, the next stage was to turn these definitions into software and service realities. Early on in this phase, it was decided that whatever was developed would be standards compliant and, as far as possible, be developed as open source software, in terms of both its development tools and the resulting products and services.
Similarly, the project would use existing technologies as far as possible to provide the 'glue' between various technologies. This would allow the project to use many existing technology solutions in new and innovative ways. The decision to favour open source presented a challenge for the project since the partnership included companies that needed to see a route to new income streams from their 'foreground' intellectual property. The project thus also developed an agreed exploitation plan.
The fundamental technical requirements of the ICING system were that it would allow citizens, using a variety of platforms (mobile phones, PCs, PDA) to interact with services provided by the local city authorities, and that these services be seamless and intuitive.
The technical work divided into two types. The first was the development of a Service Oriented Architecture system called IISYS (ICING Integrating System), designed to handle requests and responses from individual software components developed by the ICING partners. These services were based on multiple inputs from users on multiple platforms in many formats. Individual components managed these inputs and might, for example, add additional information such as location. IISYS was able to 'broker' these data and pass them onto other service components in a format they could handle. IISYS also maintained a user database so that citizens could register for a service and have an enhanced range of options available to them (for example, access to information about their issues over time and how they were resolved).
IISYS worked with a number of 'provisioning' software components that allowed additional functionality for end user services. These included the Multi Access Gateway: which component allowed for many different types of access to the services (mobile phone, instant messaging clients, SMS, email); the Multi Modal Gateway which allowed responses from services to be correctly formatted for the terminal device (PC, mobile phone, PDA); and iSmart which allowed location based services such as mapping and routing (e.g. find the nearest person to me that is also in my group).
Another aspect of the work was development of pilot services that would demonstrate the functionality of IISYS and the software components that were developed. Several pilot services were developed, a small sub-set of which are discussed below.
The ICING Urban Mediator
The ICING Urban Mediator (IUM) is server-based software that provides a way for communities to mediate local, location-based discussions, activities and information. IUM uses a map-portrayal service as a means of representing location-based information. It complements this with a set of tools for users to process, share and organize this information. The software and related web-based services enable users (e.g. citizens and city administrations) to obtain and share information about a city or neighbourhood or any other place represented in the map.
The ICING Tag reporter
One of the services that citizens identified as being important to them was one that would allow them to make a 'one-click' report of an issue, such as graffiti or parking obstructions, that they came across during normal daily activities. Before ICING, this involved either a phone call or waiting until they arrived at a PC where they could report online. There were two problems associated with this service that we had to solve. One was to provide a location for the issue, no matter how it was being reported (camera phone, non-camera phone, GPS-enabled phone, non-GPS-enabled phone). The second was to develop a software tool that could complete the task with minimal imposition to the user, the phone, the network load and the city.
In the end, we developed a pictogram that could be attached to particular pieces of street furniture. This pictogram was related to a specific item of street furniture at a specific location. It was humanly readable and contained information that a person could easily identify. With careful design, the tag was not visually intrusive and its use could both initiate and complete a transaction. In collaboration with a company called DAEM in Barcelona, we developed the pictogram, the image decoder and the phone application. It can work in a number of ways. In the case of a non-camera phone, the user can simply SMS text the code number to a city short code or phone number. The code registers the issue, the location and the user and returns a confirmation to the user. In the case of a camera phone, the image decoder converts the pictogram into a URL, the URL links to a web form that can be used to return the basic issue (click to submit) or the user can add more information to the message (bin is full, seat is broken, etc.). This is returned over the web to the city who can then confirm to the user that the issue has been received and will be dealt with.
In order to demonstrate the flexibility of this tool, ICING implemented the 'tag reporter' service in two ways. The first, in Dublin (using the tag shown in Figure 1), returned the information through the IUM to a map interface in the city offices, from where the issues were routed to the relevant city department. Registered ICING users were able to follow issues on the map interface and to add additional comments on the issue. In the second implementation, the issue was returned over the IISYS platform to the Barcelona IRIS City Customer Service Department. IRIS was not developed by ICING but, because of the open nature of the IISYS design, they were easily able to pass messages between the two systems.
[FIGURE 1 OMITTED]
As a spin-off from this service, and to demonstrate a Europe-wide integration of the ICING system, the issues raised with these two implementations could be aggregated to a continent-wide representation. While the issue of full bins might be trivial in terms of a European-wide representation, other situations could exist where information needs to be aggregated at a continent-wide level. One could imagine air pollution incidents, for example, being tracked across the continent.
The ICING Instant Messenger (IIM)
The ICING Messenger (iMessenger) is one of the mobile device modules that allows ICING cities to communicate effectively with their citizens using mobile phones. It is closely associated with the Multi Access Gateway (MAG). MAG provides the server which the iMessenger uses to communicate with other ICING components.
FEED