Ingy
Multidisciplinary Engineer (Embedded Systems, Front-End, and F-S Development)

Study phase

WO Bachelor 3, WO Pre-Master, WO Master, HBO Bachelor 4, HBO Master

Region

Utrecht

Days

4, 5

Required languages

English

Function

Design, Engineering, ICT, Research & development

Industry

Information & Communication Technology (ICT)

Months

4, 5, 6, 6+

Vergoeding

€ 400.00

About us

Ingy is a fast growing and well-funded start-up developing smart lighting and building systems. We were founded 2 years ago with a mission to deliver smart building technology at a far lower cost-price by integrating all required technology in the lighting. Furthermore is Ingy globally recognized as one of the leaders the field. They use the lighting infrastructure to make buildings smart, offering solutions like: indoor navigation, asset tracking, occupancy analytics and climate monitoring.


They have a globally spread team of world-class developers for instance in London, Madrid and Melbourne, most with first degrees (Msc or Phd) from world class universities in computer science, embedded software or wireless technology.

Job description

1. Embedded

1.1 Firmware driver DALI

Summary: create a cross-platform (Silicon Labs and Nordic Semiconductor) firmware driver for DALI.

  • Should not rely on PWM or ADC peripherals.
  • Should be able to send and receive commands over non AIN pins.
  • Should have a proper HAL abstracting away the details of SiLabs and Nordic, so it’s easy to maintain the code and potentially port to yet another platform in the future.

Currently, Ingy relies on a driver that is written by Nordic that makes use of the PWM and ADC peripherals and has quite some overhead.


1.2 Bandwidth optimization

Bandwidth optimization in-network as well from the phone to the embedded devices.

  • Increase the effective size of BLE packets from phone to firmware by implementing an improved protocol. This should work for both iOS and iPhone.
  • Implement a standard mechanism to send over a large chunk of data in an atomic fashion.
  • Increase asset tracking throughput by aggregation of multiple packets into one Wirepas packet.
  • Implement an approximate filtering mechanism that allows us to selectively send messages say only every 5 minutes for devices that are sending out every second.
    • Naively one would store all MAC addresses and only send data when a MAC address hasn’t been seen for 5 minutes. With many tags this won’t work.
    • Use a Bloom filter or Cuckoo filter instead, so we only store “approximate” MAC addresses.

1.3 Firmware Robustness & Architecture

This is a very fundamental assignment. Improve the firmware w.r.t. computer science principles, such as atomicity, loosely coupling, etc. Introduce a level of indirection to accomplish a better architecture there where required.

  • Make sure relevant actions are atomic, such as e.g. setting security credentials are assign a node to a site.
  • Make sure different components are loosely coupled
    • The structs in memory are generated directly from a yaml description, make sure that there is additional information in there that gives one flexibility in how to store in memory.
      • Use this information to be able to do migration from one version to the next.
    • Make sure that these improvements further enhance our backwards compatibility. For example, store each possible property with an identifier rather than an implicit offset into a table in memory.
    • Make sure memory is still limited to one flash page for configuration (and one flash page for backup).

1.4 In-network asset tracking

The Ingy network consists of thousands of devices that form a large network that does cover a large 1) industrial compound or 2) logistic hall. In these industrial complexes there is a need for very safe work environments, which requires knowledge of the presence of people. By incorporating smart tags on helmets one can adjust the local light conditions according to the safety prescriptions. There are hundreds of people on a site at the same time. The light has to react with low latency to be able to adjust correctly. In logistic halls the tags are attached to containers of which there are potentially hundreds of thousands. To be able to track those it is important that one can follow these “on the edge” while not having the computational capabilities to actually store the identifiable information (for example a MAC address) in its entirety. The assignment will address this in the following ways:

  • Study the methods for so-called approximate matching in network (variants of Bloom filters [1], Cuckoo filters, etc)
  • Study tradeoffs in network bandwidth required for communication versus local processing taking into account that neighbors see the same tags (it is distributed variant of above filters).
  • Design the asset tracking system taking also the non-functional aspects such as low-latency into account.
  • Simulate and analyze the overall behavior in a network simulator modeling also network loss.
  • Implement it in the firmware on actual devices.
  • Analyze the real-world behavior of a large scale system.

In a nutshell, the challenge is that scanning devices can’t make local decisions on tags in their vicinity, but need to implement a distributed algorithm taking into account information from their neighbors. That information should not hog the network though.

References

[1] Bloom filters for data aggregation and discovery: a hierarchical clustering approach, P. Hebden, A.R. Pearce, 2005 International Conference on Intelligent Sensors, Sensor Networks and Information Processing, Melbourne, Australia


2. Front-end

2.1 Pre-commissioning tool

Summary: Develop a pre-commisioning tool to easily design a lighting control scheme by loading in an existing CAD drawing and quickly assigning (repetitive) lighting control settings to sensors positioned in the drawing. Redesign our commissioning app from the ground-up with a more intuitive UI and look and feel.

2.2 Frontend AWS

The front-end for the AWS backend should contain the following two aspects:

  • Commissioning
    • An Airtable-like frontend where we can provide an almost spreadsheet like interface. One should be able to do in batches what otherwise takes a long time in the app.
    • A user should be able to configure everything according to spec, without knowing yet which node is which. That last information is obtained on site.
  • Diagnostics.
    • Basically Grafana in the cloud plus some tools to e.g. find out which device is false triggering.

 

3. Full stack

3.1 Factory programmer

Summary: Create an in-factory programmer which allows a user to select in a dashboard which hardware to program, obtains the firmware for the selected hardware in a safe and secure manner from an online resource, and runs a programming action over JTAG towards the connected devices.

  • The firmware is Ingy’s IP and has to be handled very carefully and securely.
  • The hardware has to run through a sequence of tests using our end-of-line software.
  • It must be possible to query an online database on which manufacturer has programmed which firmware for which hardware at which time
  • It must be possible to have a route that works if the in-factory programmer is offline for a couple of days.
  • The procedure to upload new firmware for particular hardware must be fully automated from the side of Ingy.
  • The procedure to obtain new firmware must also operate under the constraints of the Great Firewall of China, that is, for example, the operator might send an email to an Ingy account upon which automatically the firmware is send back to that operator in encrypted form. This is then uploaded to the gateway through a dashboard.
  • The firmware should come with an expiration date. Renewing the expiration date should be automatically when there is no firmware release.
  • Renewing the expiration date should also work under the Great Firewall of China. Again, an email might be send upon a code is received that the operator must upload to the dashboard. The code is again signed and encrypted. When there is new firmware available, the operator will get the new firmware instead.
  • The programmer will be integrated seamlessly with the Ingy license server.

3.2 Continuous documentation and testing

  • Build a documentation server (e.g. nuxt or next) with user accounts where people can have selective access to documentation
  • People should be able to log-in themselves and select a gateway (or choose a MAC address) and example JSON scripts should be pre-filled
  • Create a mechanism in which parts of the documentation for the site is auto-generated.
  • Also automatically generate the corresponding manuals
  • Separate out the texts / language in json files so we can do internationalization.
  • Incorporate the testing framework such that the results are shown per product and for the app. Similar to the “Build passed” feature with projects that use “continuous integration”
  • Make sure the tests are run in a continuous testing setup (using Bitbucket pipeline).

Contents

  • It should be neatly integrated with the "normal" website where "normal" employees can add information in a WYSIWYG manner. Should be as simple as Wordpress but impossible to hack.
  • Manufacturers and other partners can obtain information required for their hardware or their projects.

3.4 OTA (over-the-air) programming over BLE

Implement an OTA process (OTAP) using direct phone to device communication. This is a very tough assignment given that Wirepas officially doesn’t even support Bluetooth connections (or e.g. the use of the Nordic SoftDevice) in parallel to their firmware stack.

  • Implements in the firmware a GATT based server
  • Implements the update process from the phone towards that given device.
  • Updates the Wirepas mesh with this firmware
  • Ideally include MQTT uplink support on the phone to implement a cloud interface for the OTAP.
  • Ideally both working on Nordic Semiconductor as well as Silicon Labs hardware.
  • Ideally both working on Android and iOS.

3.5 Customer support tools

Implement tools for customer support when the only thing on site is a phone with the Ingy app. This is not just implementations of screens, it’s fundamental architecture that enables a very smooth customer support infrastructure.

  • Incorporate MQTT support for the phone (on a server) so the phone can be reached as soon as the user subscribes to a server for a customer support request.
  • Implement MQTT support on the phone itself also for local purposes. Rather than sending directly a wireless command, the command is send to a local MQTT broker which then maps it to something remote or something local.
  • Implement MQTT commands that are “terminating” in the phone or in the gateway rather than in the Ingy network itself to be able to query status information remotely.
    • Incorporate a basic representation of the gateway(s) in the app as part of this.
  • Implement MQTT commands that actually take the user from screen to screen and allow the support employee to see the results as well. This is different from above. It makes every editable and clickable field in the app and makes it available as endpoint.
  • Create fault diagnosis workflows. The user should be able to go step by step through diagnosis flows. With the above support, the support employee can interactively take them through that flow.
    • Have diagnosis in there of the phone, of the network, etc.
  • Log every interaction of the user by logging all MQTT requests.

These are three separate assignments, students will only apply for one.

Requirements

Preferred requirements are:

  • Computer science/software development (you can be on the entire range from embedded and very close to the hardware all the way to latest in cloud development)
  • Electrical engineering (but preferably with some knowledge of at least C/C++ programming)
  • Wireless and large-scale mesh networking
  • Machine learning/Artificial intelligence/statistics (but combined with the coding skills to implement your models into a real-world implementation, e.g. beyond Matlab)
  • UI / UX design
  • System administration and technical support with a focus on Linux and AWS

These are however not hard criteria, it mostly depends on the type of internship he/she wants to execute as Ingy has multiple internships to offer.

Working conditions

·      You will learn to operate in a fully remote, agile development environment with world class engineers

·      At the start daily supervision from one of our experienced developers (reducing to standard supervision for a fulltime graduate employee at the end of the internship)

·      We provide a laptop and all material needed for you to operate

·      Experience life in a well-funded disruptive start-up

Apply