brentstineman / transit-iothub-demo Goto Github PK

This action item handles the "validate ticket" event from the simulated gate/reader and includes defining the request and response message payloads. This action item will receive a validate request from the simulated device and respond with either an accept or reject response. The exact response sent will be random and the percentage chance of a negative response should be configurable.

This action item handles the "gate direction change" event from the simulated gate/reader device and includes defining the message payload. This action item will simply receive the request, no response or other action is required.

The simulated device includes a locally stored file that holds various values used by the device. The system administrator needs the ability to force the device to update this using a new version stored in a remote location.

This REST API will command the device to update with a new file that is stored in Azure blob storage. The new file will be designated by a SAS token URL and with an arbitrary version ID (string).

Create the base class to be used by both the kiosk and gate/reader device simulators as well as the base event message (which includes: device type (string), device id (string), message type (string), and timestamp (timestamp)).

Recommended implementation will be a C#/.Net Core UWP application. Will evaluate other options based on team skill sets.

Common Device Properties include: device type (string), device id (string), station/location (string), metadata version (string), state (enabled/disabled/failed)

Devices will be run on developer workstations at first, but may be deployed to Azure VMs for continual testing (time allowing). May consider containerization depending on team skill sets. Device simulator will have a "common" foundation class and the two specific devices will inherit from that one.

All operations in the simulated device will write out to a local file. These log files can optionally contain periodic rotation and file curling (removing older files) if time allows).

The base device will include a single "send message" function that will be used to send any messages.

This action logic will receive all messages (including heartbeat notifications) and use their enqueue time to update a redis cache for all devices. The cache will contain device ID and enqueue time.

This tasks also includes ensuring that all other messages are forwarded to this new action logic.

The simulated device includes a locally stored files that are the logs of the device actions/operations. The system administrator needs the ability to force the device to upload this information so it can be review/analyzed.

This REST API will command the device to upload its log files to the store location configured in IOT Hub.

The device will be expected to send a message periodically to indicate it is "alive" and operating. The heartbeat should be sent a minimum of nn seconds (determined by device configuration file). If the device sends any other action message, the heartbeat counter will be restarted so that heartbeat messages will only be sent during idle periods.

Additionally, the device will have a random chance to simulate a short lived communication failure. The percentage chance for this will be determined by the device's configuration file.

This will be implemented in the base device class so it will be inherited by all derived classes. This task also includes defining the heartbeat message format.

The "enable device" API will be enhanced to add in a new, optional value to indicate that the device operation count should be reset. This will simulate the device maintenance after a failure.

Add a new device property for state (enabled/disabled). This property should by synchronized between the simulated device and its Azure IOT Hub device twin. When the device first registers, it should default to a "disabled" state. When disabled, all simulated events should stop. When its enabled, any tracked values such as "stock" levels should be reset to the original starting values (as if the device had been recently serviced).

Using the base device as the parent, create the simulated gate and ticket reader device and its device twin. This includes documentation related to the configuration, compilation, and registration of the simulated device and its IOT Hub device twin.

This simulated device will include a method that is triggered somewhat randomly by a trigger that simulates a "validate ticket" action. The frequency of the trigger will be based on the values contained in a locally stored JSON metadata file.

When an event is triggered, the kiosk device will determine which "direction" it is set to (either entry or exit from the platform). If in entry mode, it will validate the ticket by sending a message to an action logic method and wait for either a positive for negative response. if successful, the gate will send a "open gate" notification message.

Add an action/method to the simulated device that will process a request from the management plane to upload locally stored log files.

This task includes the definition of the request message payload.

Create a quick presentation to help ensure entire team has a basic understanding of IOT Hub and how it will be used during the project.

This action logic will act on the Device Failure message. It will then update the device's status property to disabled.

This action item handles the "gate opened" event from the simulated gate/reader device and includes defining the message payload. This action item will simply receive the request, no response or other action is required.

This action item handles the "low stock" event from the simulated kiosk and includes defining the message payload (which should include current stock level). This action item will simply receive the request, no response or other action is required.

We need a way to unit test the simulated device functionality. This approach will require the ability to inject a mock deviceclient into the device classes.

Create a Power BI Desktop report that consumes the OData heartbeat status feed and displays a simple stoplight status of each device.

Green: reported within last 30 seconds
Yellow: hasn't reported within 60 seconds
Red: hasn't reported in 120 seconds

This REST based management API allows you to retrieve a list of one or more devices from IOT Hub via the service SDK. Queries may be performed by device type, or device ID. The resulting payload is a JSON collection of the current device properties.

Optionally: this query may be done for all devices at a given location.

Using the base device as the parent, create the simulated kiosk device and its device twin. This includes documentation related to the configuration, compilation, and registration of the simulated device and its IOT Hub device twin.

This simulated device will include a method that is triggered somewhat randomly by a trigger that simulates a "purchase ticket" action. The frequency of the trigger will be based on the values contained in a locally stored JSON metadata file.

When an event is triggered, the kiosk device will call a logic action that "validates" the ticket purchase and if successful, the kiosk will send a ticket issued message and decrements the quantity of ticket stock contained within it. A stock level falls below a threshold contained in the metadata file, it will issue a "low stock" award.

Platform gates are set to either allow entry or exit as needed based on the traffic flow. System administrators need to be able to set the direction of gates based on the needs of a given station. This REST API will allow for the setting of the direction of a specific gate/reader device via a directly method update. When the change has been applied to the simulated device, the device will send a message to a action logic.

The enable device action will be updated to accept a new property that will also reset the device counter. This will simulate device maintenance having occurred.

This action item handles the "ticket issued" event from the simulated kiosk and includes defining the message payload. This action item will simply receive the request, no response or other action is required.

Add an action/method to the simulated device that will process a request from the management plane to update the local copy of the metadata file with a copy specified by a storage account SAS URL. The simulated device will also update its metadata version id with the new setting specified by the request.

This task includes the definition of the request message payload.

This REST base API will be hosted in an Azure function and allows a system administrator to enable or disable any device. This will be implemented with a device twin property update and its synchronization with the simulated device.

Create and use an enum in place of all strings for device types and message types. Should also add validation for this in the Get Device API

Create a project intro deck that goes over the high level scenario and the goals/approach for the week.

Add a new property to the gate/reader device for direction of the gate (entry or exit). When the property is changed, the device should send a message (payload definition is part of this task).

This OData API will return the current contents of the heartbeat redis cache. the format of the result will be odata so that it can be consumed by PowerBI.

This action item handles the "purchase ticket" event from the simulated kiosk and includes defining the request and response message payloads. This action item will receive a purchase request from the simulated device and respond with either an accept or reject response. The exact response sent will be random and the percentage chance of a negative response should be configurable.

Device hardware will fail periodically. So the device simulator will also need to replicate this behavior. To simulate the life expectancy of various device components, these failures will be based on operation cycles. For the reader/gate device, the chance of failure will occur after nn gate openings. For the ticket kiosk, the chance of failure will occur after nn tickets has been printed. The operation count will be set in the devices configuration metadata. The chance of failure will increase the further past the target operation count.

When the device "fails", it will send a failure message (payload definition of part of this task) and set itself into a disabled state.

this code

this won't compile because ForEach method isn't on IEnumerable & ForEach returns void, doesn't construct an output list.