Innovation Days 2023

Description: Using the screenshot functionality from the Polaris ASD, we would connect to TargetProcess API to automatically create a ticket, fill in the build version as well as additional valuable information. Reducing the time spent on filling bugs, and to allow our customers to report their findings quickly and intuitively. Once developed it would support also our internal or external large scale validations.
Participants: Jan, Kristinn
Team Size Estimate: 2-3

Description: ChatGPT is already proving to be useful for many things within tern. This project will explore possibilities on how to use features from ChatGPT to design new automated test cases or to include them in the testing process. The new visual recognition capabilities could be used for various front end testing, like for example measuring response times of an interface during testing and creating a report that tracks the times and analyses them afterwards.
Participants: Pawel, Ásgeir
Team Size Estimate: 2-3

Description: How many times, when you asked ChatGPT for the ATM related information, it answered you with rubbish or, even worse, with the instructions how to withdraw the money from the cash machine (ATM != ATM...)? Before we get to AGI, to put ATM domain experts (like me :) ) out of work, it would be necessary to create a ChatGPT-like tool that would be trained on the set of relevant data (documents from ICAO, Eurocontrol, user manuals for ATM systems, etc.) without polluting the information set with data that is not useful for this particular task. As a proof of concept, we can try to train a simple Llama model (open source from Meta) on our user manuals and see if this would be useful for retrieving relevant data in an easy and fast way. Such a model, if successful, can be deployed locally and become part of Nexus. Later it can grow to consume more information and in the long run threaten the position of domain experts and ATC instructors ;)
Participants: Pawel
Team Size Estimate: 2-3

Description: Nexus is slowly becoming an integral part of the Polaris setup, enhancing its capabilities by providing users with the information they need to carry out operations efficiently. The idea is to explore the possibility of calling up the Nexus function and retrieving relevant information directly from the Polaris ASD (track labels, lists, etc.). This would make Polaris+Nexus a powerful ATM setup that is currently unrivalled in the market. Example use cases: 1. Displaying the aircraft performance page in Nexus after clicking on the track label on the ASD (for the specific aircraft type as the one clicked on the ASD). This would help to plan the air situation by providing information on the possible rate of climb/descent (at the current FL), the possible max/min speed, the possible max FL that the particular aircraft type can take, etc. 2. Providing airport details (last METAR, NOTAMs, AIP chart, landing distance available, etc.) after clicking on the ADES/ADEP field on the ASD. Useful for day-to-day and emergency situations. 3. Display of spot wind information on Nexus (from GRIB2) for LAT/LON or track position (+FL) clicked on the ASD. 4. Decoding the information from the flight plan (location indicators, aircraft type, callsign). We can probably use some kind of gRPC interface for this, but I need a technically skilled person in a team to find the best way to do this :) Anyway, I think it would be a jaw dropping game changer.
Participants: Pawel
Team Size Estimate: 2-3

Description: Add a new feature inside the ASD that allows various actions and commands to be accessible from a simple keyboard searchable list. The action list could contain many different types of actions like toggling map layers, issuing clearances, changing map preferences and more. This can allow power users to act quickly using only the keyboard (rather than mouse and finding a specific button) and also makes discoverability of seldomly used actions easier. Inspired by the Command Palette feature from Visual Studio Code (IDE).
Participants: Davíð Sindri, Hayfa, Snorri, Þórir, Pawel
Team Size Estimate: 2-3

Description: Use a large language model like GPT 4 to breathe life into our coding standard and make it a more useful documentation by integrating it in to our VSCode dev environment. The project is about building a plugin that interacts with GPT 4 and uses our coding standard as an input along with the code being written. The plugin should give useful guidance to the programmer so that he/her can easily follow Tern's coding standard.
Participants: Axel Þór, Guðjón Hólm
Team Size Estimate: 2-3

Description: Leveraging the power of open source AI tools we could feasibly create a relatively simple tower controller that could both understand speech and respond correctly to queries. This AI tower controller would have the ability to give directional instructions, alerting the student of scenarios, controlling the stop bars or other lights and even supply scenario specific information. This same module could feasibly be used as a pseudo pilot for Orion Tower.
Participants: Sindri, Judy
Team Size Estimate: 2-3

Description: Gathering valuable measurements about system behavior and performance is key to success. We can’t line up dozens of deployments of the system currently still in development, but we can prove what the system is capable of after each system test, or manual large scale validation exercise (and automated test, but let’s keep this simple here). This information is crucial for data driven decision making and also to build trust and interest in the system. Facts don’t lie (ideally). Examples range from SDP and FDP related statistics to responsiveness of the interface with a certain load at specific times. The output would help us internally to enrich test results and help evaluations. Business development would then receive figures about loads the system was tested with, etc. Scope: Analyze data available from component logs Pick a specific component Define indicators to be collected Build a prototype of a tool/script which would capture data from logs and deliver the measurement for a given period of time
Participants: Jan, Ari, Þröstur, Þór
Team Size Estimate: 2-5

Description: Lately, there has been huge interest in CWPs working within a browser. From our perspective it is mainly to support secondary level use cases for smaller airports, or non-operational stakeholders within ANSPs and Airports. While, some ATM providers, our competitors are evaluating developing Air Situation Displays in REACT, etc. If we could modify AIR to digest surveillance data from sources available domestically, we can set up a screen with Air somewhere within the office, which would be a great attention grabber by individuals and potential customers visiting our premises. In the future this might even find its place as a submodule within NEXUS.
Participants: Jan
Team Size Estimate: 2-3

Description: We don't have a meeting room map here in the Icelandic office. It would be nice to make one based on an existing map and to mark the existing meeting rooms. An important point is to make it easy to add and remove a room on the map easily since the floor plan of Tern Iceland keeps changing. If there is extra time, we can make emojis of the staff employees using the ternling list and place them on a separate copy of the floor plan too and add them to the google spaces of Tern. If so, it'd be good to get a floor plan of the Hungary office.
Participants: Judy
Team Size Estimate: 4-5

Description: Let's see if we can use the power of AI to help us write better manuals faster. Our user manuals are written by a lot of different people, often a bit as an afterthought. This results in inconsistently written manuals, with different uses of grammar and style between sections. Furthermore writing manuals takes time, which could be spent elsewhere. Seeing that ChatGPT is rather good at writing consistent readable texts I want to explore if we could use it to help us write manuals.
Following are some topics that can be looked at:
1. Rewrite existing parts of the manual to a consistent style following general best practises for writing manuals.
2. Extend this to investigate whether we could use AI to read in our Implementation Proposals and use these to extend existing manuals with the new features. This could reduce work in future feature sprints.
Participants: Marijke, Judy
Team Size Estimate: 2-3

Description: Data Warehouse is a big concept which needs to be analyzed further. The idea for this project is to work on two streams:
1. A business proposal, use cases, market assessment etc.
2. A technical proposal, data point definition, cloud services assessment and possibly a simple prototype.
Participants: Heimir Örn Hólmarsson, Heiðar, Kolbrún, Hannes, Jan, Pawel
Team Size Estimate: 1-5

Description:Explore the idea of running the polaris-mag sandbox in a virtual machine. If it's viable, we could automatically build images and snapshots of the sandbox in various states (even in the middle of a running test or playback, etc.), thus further reducing the need for manual setup and configuration. Possible downsides are image size and resources needed for executing the VM.
Participants: Bálint, Norbert
Team Size Estimate: 2-3

Description: Being able to run the air situation display without user interface, and query the state of properties, models etc. via command line/python script. This would help testers to create component tests and integration test that would be part of the build chain.
Participants: Lovísa Irpa Helgadóttir, Helgi Rúnar
Team Size Estimate: 2-5

Description: As network infrastructure is sometimes the responsibility of the customer, not Tern Systems, we have no control or access to the configuration of networking equipment, including firewalls. We frequently encounter issues where the customer has misconfigured something, resulting in loss of network connectivity on some ports between some machines. Up until now we have verified connectivity manually and by using indicators on our SMC. We publish a list of ports used for communications, where we specify source host type, destination host type, network protocol and port. The customer uses this list to create firewall rules and routing entries. This list in the Polaris MAG contains 240 entries, where in some cases there are multiple host types for source and/or destination, so the final count of connections is a larger number.
The idea is to create scripts to read the port list and automatically find ports that are closed, which would eliminate work that has been very time consuming on site.
Participants: Ólafur Valsson, Gústav, Davíð Gunnars
Team Size Estimate: 2-3

Description: It is useful both for us and our clients to have an estimate for the maximum number of flights our systems can deal with at a time. We can estimate this number through capacity testing, where we create scenarios with increasing numbers of flights and see when the systems start failing. The trick is to find a clear indication that a system has failed to be able to say that it cannot handle however many flights we just fed it. For example, SNS has a very simple criteria for this: if it is not able to finish probing all flights for all safety nets within a fixed time window, it has failed. It also prints in its logs how long it took to probe all flights every probe cycle. We can read those logs and see when that time exceeded the length of the cycle. Let's write some Python to use Tatoo to generate increasing numbers of flights. We can run each scenario for a few minutes and check the logs to see if SNS did all right. Every pass or failure will let us binary search for the capacity of the system. Once we figure out a good way of doing this for SNS we can take what we learned there and apply it to our other systems.
Participants: Gunnar Þór Magnússon, Davíð Örn, Stefán, Davíð Halldór
Team Size Estimate: 1-3

Description: Our systems communicate using two binary formats; protobuf and Asterix messages. For both of those we have parsers that take the wire format and deserialize it into our own classes. Failures in this process have brought down our services; recently SNS hit an unhandled exception caused by parsing unexpected input that stopped a thread that was processing incoming messages from a queue, effectively causing the system to halt. Fuzzing is a technique in software testing where we generate plausible-looking inputs to a system and see if it handles them gracefully. We can pick a protobuf schema, or one of the simpler Asterix messages (maybe Cat 62 or 65), and write a program to generate messages where some fields are valid and some are not. If we feed those to our message parsers we should uncover new bugs, and could make this part of the CI pipeline's automated tests from now on.
Participants: Gunnar Þór Magnússon
Team Size Estimate: 1-3