AWS Public Sector Blog

How to build smart cities with FIWARE Orion Context Broker and Cygnus on AWS

Efforts to realize smart cities have been implemented around the world. The city of Santander in Spain embedded more than 12,000 sensors throughout the city to utilize data to reduce environmental issues such as chronic traffic congestion and air pollution. The city of Lisbon in Portugal introduced an intelligent city infrastructure platform to integrate more than 30 systems, including those for transportation and energy, to help improve the quality of services, public safety, mobility, and operational effectiveness for citizens and visitors by collecting and analyzing data.

These cities both use FIWARE, an open source framework supporting the development of smart solutions, like smart cities. FIWARE leverages sensing data from Internet of Things (IoT) devices, then collects, stores, and analyzes data with an API call. One FIWARE component, Orion Context Broker, gathers context information from diverse sources such as mobile apps, IoT devices, and social networking services, and manages the lifecycle of this context information, from registrations, updates, queries, and subscriptions. Context information Orion Context Broker consists of entities (like a car), and its attributes (like the speed or location of the car). With Orion Context Broker, you can subscribe to dynamic context information, so when some condition occurs and the context elements change, you receive a notification. In Japan, cities like Takamatsu and Kakogawa leverage Orion for disaster prevention and public safety. Recently, MODE, Inc. announced that it completed the validation of its data integration test with Orion.

Orion Context Broker stores the last state of data into a database, so you need to deploy the FIWARE component Cygnus, which is a connector in charge of persisting Orion context data, and keeps historical data in configured third-party databases, in case you would like to see a historical view of the data for analysis.

Orion is increasingly being used to realize smart cities, but it needs to run these components on cloud services such as Amazon Web Services (AWS) to maintain the high availability, durability, and security required to connect to a large amount of IoT devices, and to integrate with other systems to leverage data. These components can run as a container using docker, so using Docker Compose can link Orion Context Broker and Cygnus to databases such as MongoDB and PostgreSQL. In addition, you can use AWS database services to improve performance, scalability, and durability.

In this blog post, we address building Orion Context Broker on AWS. We have created a sample and released it on GitHub for deploying Orion Context Broker and Cygnus simply on AWS. Read on to learn how to deploy Orion Context Broker and Cygnus on AWS with AWS Cloud Development Kit (AWS CDK) and Docker Compose quickly.

Architecture overview

Orion Context Broker and Cygnus run as containers on AWS Fargate, and Amazon Elastic Container Service (Amazon ECS) manages them. The last state of data is stored into Amazon DocumentDB, through which Orion Context Broker connects. Historical data is stored in Amazon Aurora Serverless via Cygnus. Using these databases provides high scalability, performance, and availability without worrying about management tasks. Figure 1 shows this architecture. Networking resources (such as Amazon VPC, subnets, security groups, and NAT Gateway) and databases are built and deployed with AWS CDK. Orion Context Broker and Cygnus are deployed as containers on Amazon ECS with Docker Compose.

 Figure 1. Orion Context Broker and Cygnus architecture on AWS.

Figure 1. Orion Context Broker and Cygnus architecture on AWS.

Prerequisites

Deployment

1. To deploy networking resources and databases, run the following command:

./deployer.sh <AWS_PROFILE>

2. Run the following command to start Orion Context Broker and Cygnus:

docker compose -p orion -f docker/orion/docker-compose.yml up

docker compose -p cygnus -f docker/cygnus/docker-compose.yml up

Check applications work

Run curl command and you see outputs as follows:

$ curl http://<Your ALB DNS name>:1026/version

#Outputs
{
"orion" : {
"version" : "3.1.0-next",
"uptime" : "1 d, 1 h, 19 m, 33 s",
"git_hash" : "7bd1e43514539bd65caeb30d4e3319202e0f115b",
"compile_time" : "Mon Jul 26 08:19:44 UTC 2021",
"compiled_by" : "root",
"compiled_in" : "dae1c5e3a7d9",
"release_date" : "Mon Jul 26 08:19:44 UTC 2021",
"machine" : "x86_64",
"doc" : "https://fiware-orion.rtfd.io/",
"libversions": {
"boost": "1_66",
"libcurl": "libcurl/7.61.1 OpenSSL/1.1.1g zlib/1.2.11 nghttp2/1.33.0",
"libmicrohttpd": "0.9.70",
"openssl": "1.1",
"rapidjson": "1.1.0",
"mongoc": "1.17.4",
"bson": "1.17.4"
}
}
}

To check POST, GET, and PUT, run the following commands and you can see outputs as follows:

#POST
$ curl -sS http://<Your ALB DNS name>:1026/v2/entities \
-H 'Content-Type: application/json' \
-H 'fiware-service: demo' \
-H 'fiware-servicepath: /' \
-d @- <<EOF
{
"id": "living",
"type": "Room",
"temperature": {"value": 23, "type": "Float"}
}
EOF

#GET
$ curl -sS http://<Your ALB DNS name>:1026/v2/entities/living?type=Room \
-H 'fiware-service: demo' \
-H 'fiware-servicepath: /' \
-H 'Accept: application/json'

#Outputs
{"id":"living","type":"Room",
"temperature":
{"type":"Float","value":23,"metadata":{}
}
}

#PUT
$ curl -sS http://<Your ALB DNS name>:1026/v2/entities/living/attrs/temperature/value \
-H 'Content-Type: text/plain' \
-H 'fiware-service: demo' \
-H 'fiware-servicepath: /' \
-X PUT \
-d 35

#GET
$ curl -sS http://<Your ALB DNS name>:1026/v2/living?type=Room \ 
-H 'fiware-service: demo' 
-H 'fiware-servicepath: /' 
-H 'Accept: application/json'

#Outputs
{"id":"living","type":"Room",
"temperature":
{"type":"Float","value":35,"metadata":{}
}
}

To store historical data, use subscription features. Run the following command and you can see outputs as follows:

curl -v -sS http://<Your ALB DNS name>:1026/v2/subscriptions \
-H 'Content-Type: application/json' \
-H 'fiware-service: demo' \
-H 'fiware-servicepath: /' \
-d @- <<EOF
{
"description": "A subscription to notify info about living",
"subject": {
"entities": [
{
"id": "living",
"type": "Room"
}
],
"condition": {
"attrs": [
"temperature"
]
}
},
"notification": {
"http": {
"url": "http://cygnus.cygnus.local:5055/notify"
},
"attrs": [
"temperature"
],
"attrsFormat": "legacy"
},
"throttling": 5
}
EOF

#Outputs
* Trying 13.112.132.125...
* TCP_NODELAY set
* Connected to <Your ALB DNS name> (xx.yyy.xxx.zzz) port 1026 (#0)
> POST /v2/subscriptions HTTP/1.1
> Host: <ALB DNS name>:1026
> User-Agent: curl/7.58.0
> Accept: */*
> Content-Type: application/json
> fiware-service: demo
> fiware-servicepath: /
> Content-Length: 358
> 
* upload completely sent off: 358 out of 358 bytes
< HTTP/1.1 201 Created
< Date: Thu, 19 Aug 2021 05:25:47 GMT
< Content-Length: 0
< Connection: keep-alive
< Location: /v2/subscriptions/611deb5ba876a01e6864a63c
< Fiware-Correlator: e8d3ccbc-00ad-11ec-97b3-0a58a9feac02
< 
* Connection #0 to host <ALB DNS name> left intact

After updating context several times, you can see that historical data is stored in Amazon Aurora like this:

select * FROM demo.living_room;
recvtimets | recvtime | fiwareservicepath | entityid | entitytype | attrname | attrtype | attrvalue | attrmd 
---------------+-------------------------+-------------------+----------+------------+-------------+----------+-----------+--------
1629351404138 | 2021-08-19 05:36:44.138 | / | living | Room | temperature | Float | 22 | []
1629351409412 | 2021-08-19 05:36:49.412 | / | living | Room | temperature | Float | 17 | []
1629351413194 | 2021-08-19 05:36:53.194 | / | living | Room | temperature | Float | 28 | []

Application logs are stored in Amazon CloudWatch Logs, so you can view them as needed.

Conclusion

This post shows how to build and deploy Orion Context Broker quickly and easily with AWS CDK and Docker Compose. This helps you deploy it or other container application on AWS with them. Next step, to learn more about AWS CDK, see the CDK Workshop or to know other ways about deploying container applications on AWS easily, try AWS Copilot. Using these can help you reduce manual steps and focus your time on business logic.

Learn more about AWS and smart cities in the City Transformation hub. Read more stories about how AWS is helping state governments create innovative solutions and smart cities.

More related AWS and smart cities resources:


Subscribe to the AWS Public Sector Blog newsletter to get the latest in AWS tools, solutions, and innovations from the public sector delivered to your inbox, or contact us.

The AWS Public Sector Blog needs your help. Please take a few minutes to share insights regarding your experience with the AWS Public Sector Blog in this survey, and we’ll use feedback from the survey to create more content aligned with the preferences of our readers.

Masahiro Imai

Masahiro Imai

Masahiro Imai is a senior solutions architect in Japan’s public sector for Amazon Web Services (AWS). His area of expertise is machine learning. He helps AWS customers use AWS services for their smart city projects and hopes to apply machine learning to many smart services in the public sector in the future. On weekends, he loves riding motorbikes.

Hidenori Koizumi

Hidenori Koizumi

Hidenori Koizumi is a prototyping solutions architect in Japan’s public sector for Amazon Web Services (AWS). He is an expert in developing solutions in the research field based on his scientific background (biology, chemistry, and more). He has recently been developing applications with AWS Amplify and AWS CDK. He likes traveling and photography.

Jorge Lanzarotti

Jorge Lanzarotti

Jorge Lanzarotti is a prototyping solutions architect in Japan’s public sector for Amazon Web Services (AWS). He loves to use his computer science skills to build scalable and resilient architectures that are easy to deploy and maintain. He has years of experience working and creating platforms in the healthcare and BI markets. Living in Japan since 2016, he enjoys snowboarding and the Japanese culture.