Costcade

Inspiration

Building infrastructure all around the world give fragmented information about their health and conditions, and once things break and confusion ensues, we can't quite learn from our mistakes and come up with better safety protocols since we don't even know what happened and how. Costcade seeks to fill in the gap where we don't know what should be done if an outage were to occur and what costs may occur.

What it does

Costcade allows users to see in real time...

Where an outage has occurred,
Which other components of a building will be affected by this outage,
How much time will it take before service level agreements (SLAs) are breached,
How much money will be paid as a result,
and what actions are there to take, ranked by the costs avoided by taking those actions.

Using a dependency graph, Costcade represents each major component of a building as a set of connected nodes, where a directed edge from A-->B means B is dependent on A. This means when an outage occurs in A, then after a certain delay, B will experience an outage as well. Since components are interconnected, one outage can quickly grow into many outages.

Every second, an update is applied to the graph in response to states and click events.

A click event is there the user clicks on one of the nodes to introduce a fault (also called outage).
When a node is in a faulty state long enough, any nodes dependent on it may also become faulty.

What it does NOT do (out of scope)

Machine learning-based predictions
Dynamic, on-demand generation of action items
Calculations of costs beyond SLA breaches
Third party notifications for users

How we built it

First, we began by defining our scope of what we can build in this limited amount of time and what may be a stretch.

Then, we built the backend using FastAPI, first starting from the endpoints and then fleshing out to the specific functions that do the math.

One of the most important parts of the backend is the graph, which we modeled using DiGraph from Python's NetworkX. Since we knew that infrastructure of a building typically does not change and only the health of each component (outage, normal operation) does, we created a building.json file that represents each graph statically and a separate dictionary that holds each faulty node. This dictionary is continuously updated and applied to the graph every second so that faulty nodes show up as faulty.

In order to effectively simulate for a demo, we made it so that each second in real time represents 60 seconds in the simulation itself. The system continuously polls (asks) the backend if the state of the graph has changed, and if it has (e.g. if a fault happened, if time has passed during a fault and a dependent node is now faulty, etc.), then the changes will be reflected.

Challenges we ran into

Since we didn't know much about NetworkX, it was a challenge to learn about it and how to integrate it with this real time system.
Deciding the minimally viable scope of this project was also a challenge since judgement was needed to determine if a notification system, more robust and credible building infrastructure schemas (such as Brick Schema and it's native RDFlib library), and any advanced way of producing actionable steps beyond static data was feasible in time constraints.
- While we acknowledged that heavy costs can be incurred for damages that do not breach SLAs, we decided focusing on SLAs was vital because of CBRE's focus on real estate.

Accomplishments that we're proud of

We are proud of successfully implementing a real time system that continuously updates. Our main backend developer has never directly worked with systems that continuously poll backend information and display them continuously to users before, so learning to isolate what information can be loaded just once (the graph itself) and what information needs to change was considered a great accomplishment.

What we learned

Using AI is completely viable for software projects, especially when speed is a factor. By understanding our business requirements, the vital data structures that power our application, and what logic we needed to implemetn, we found we could still keep in touch with how the code works.

What's next for Costcade

Since we minimized the scope for this hackathon, we seek to...

Add dynamically generated action items
Integrate a battle-hardened and credible schema for representing components of a building rather than ad hoc .json.
Integrate estimations of costs due to infrastructure damage, in addition to SLA breaches.