Olympic sailing on Eclipse technology: Eclipse Azimuth Sailing Analytics

This talk details the evolution of the SAP Sailing Analytics platform, highlighting its journey from prototype to a critical tool used in various sailing events, including the Olympics. The speaker describes how Eclipse technology, in conjunction with OSGi environments and tools like Jetty, played a crucial role in the development of a wind-based leaderboard for sailing races. The complex logistics involved in tracking boats, monitoring wind data, and integrating various technologies are discussed, showcasing the challenges faced during development. The speaker shares anecdotes from the Kieler Woche, emphasizing the impact of the platform on both sailors and commentators, and concludes by touching on its recent open-source transition and plans for future enhancements under the Eclipse project.

Good morning and ahoy everyone. So, let's start with a little video that we have prepared. You used the SAP Sailing Analytics platform. How did it go? Um I don't I think it's fairly safe to say that if I didn't have this tool, I would not have been able to do the commentary and I'm really not making that up. Um with sailing, you have to push in on

the pictures to see the expressions on people's faces. It's the job of the commentator to explain where that person is in the race. And the SAP Analytics was the only tool that I had that could do that for me. And it did that and it also did quite a lot more as well because I also had the opportunity to see all the information about the speed and

who was trying to win the race, how they were going to win the race, where the dangers were. For me as a commentator, it's it's been really powerful this week. So, in the next 15 minutes or so, you'll see how Eclipse technology made it to the Olympics twice. Sailing can be super complicated to follow. If you see a picture like this, boats on the water might be

a long distance away. You don't see the angles. Sometimes you don't even see who competes. There is ribs and motorboats following the races. There is start vessels. It all depends on the angles. You have to see the course marks. And the most important thing is you cannot see the wind and the wind really decides who is in the lead. But how did Eclipse technology get into there?

So, to understand that, we need to rewind almost 22 years, probably. So, that's when I joined SAP, and um in the introduction you heard, we did a lot of model-driven software development at the time. The mantra for SAP NetWeaver at the time was simple, robust, and model-driven. And that is where the Eclipse IDE as a tool shell uh became to play an important role for how at

SAP we integrated all these model-driven environments. As said, in the at the time I was doing OCL work. Uh we tried to use it to validate constraints in large repositories with hundreds or millions of model elements and try to make that scale. So, if you look for at owl, you might still find a bunch of commits from myself. So, that's how I came to love and appreciate

the Eclipse technology, including all the OSGi environments with Equinox at the time. And then, around 2011, a colleague came up and said, "Hey, don't you want to work in a sailing showcase?" Uh that sounded a weird, but I had some time, and I thought, "Hey, this sounds like a cool opportunity." So, I dug in and tried to understand what they were trying to to get done. And

at the time, SAP had started to sponsor the sport of sailing, in particular the sailing team Germany, which was the Olympic branch of the German Sailing Federation. Now, the task was to build what is called a wind-based leaderboard for Kieler Woche 2011 2011. If you know it, Kieler Woche always happens in the last full week of June. I was approached someone in April, so we had roughly

6 weeks of development time. And at the time, there was no cloud code or anything, so that was like handwriting code. we decided to use what we had and what we knew, and where we could be halfway sure that it would work. So, OSGi, Equinox, write a bunch of bundles, use Jetty as an embedded web server as we heard in the introduction. There was a special incentive.

My manager at the time, quite clever, he knew I was into avionics and stuff, flying RC helicopters. He said, "If you make it and can show a live wind-based leaderboard on Kilovolt live TV, you get to fly on the TV camera helicopter." So, for those not into sailing, and from the poll, I think most of you are not so much into sailing, what does it mean to

have a wind-based leaderboard? Imagine you have these two boats there, the orange and the red one, and they need to go to that next mark. The question is, who will arrive there first? So, who's in the lead? Based on that picture, you might think, "Well, the orange boat is a little closer to that mark, so probably the orange one is in the lead." Let's flip that around,

and let's add some data. If we take wind into account, and we rotate the diagram such that wind comes from the top, which is like sailors love to view these diagrams, all of a sudden that you add these advantage lines, you see that the red boat is more than two boat lengths in the lead. Actually, there's even two other boats there on the side where you can't

see them in between. So, Brazil rank one, Great Britain rank four. And that leads to that wind-based live leaderboard where you can see the distances and the ranks. That was what they had been asking for. Now, these displays have been taken from today's environment. At the time when we started, we didn't even have a Google Maps integration. So, try to remember 2011. What did we have then?

It was Java 1.6, Equinox was in version 3.6, Tycho for building in a Maven environment in 0.10, Eclipse Helios 3.6, Jetty 6.1. And at the time, the cool was uh the Google Web Toolkit 230. So, that allowed us to build the whole web UI using Java. Then, of course, beautiful SAP JVM profiler with classic dev mode in Google Web Toolkit, we could even profile our web UI.

So, that was pretty fantastic. We ran and deployed our own Bugzilla in version 3.4. Hudson was in 3.0. So, lots of Eclipse technology, especially to start with. Android support still built in Eclipse before it became Android Studio based on IntelliJ. So, we had what we needed. And then it was hacking away. You need to integrate with the GPS devices that get attached to the boats and the

marks. And as you can see from the picture, there is quite some logistics involved. Trackers need to be handed out in the morning, need to be recollected in the evening, charged overnight, assigned to the right people, assigned to the right marks. So, lots of monitoring going into that. And we need wind data. So, in order to display what you just saw on the diagram, wind data needs

to come from somewhere. Now, the picture shows the more modern type of devices. When we started, it was wires and cables and motorcycle batteries on motorboats. It was a nightmare. The protocol was UDP-based and ran through a tool called Expedition. Lots of funny stuff. But, on that Wednesday in the middle of Kieler Woche 2011, we did show the first live wind-based leaderboard. And guess what? All the

sailors flooded that tiny little studio. We had 50 people standing in front of that screen because it was not put online. Nobody knew the the URL. So, people had to come there and browse through all the displays. The hospitality program around that did work. Our co-CEO at the time, Jim Hagemann-Snabe, an avid sailor, he steered the Trivia, a 12-meter boat for those who are into racing. Those

are the old America's Cup boats of the time around the 1930s, 1940s. And Jim got to get uh two interviews on CNN and Al Jazeera. And so I got to fly the helicopter. So what started as a throwaway prototype um was really appreciated by sailors and coaches and fans alike. And they all said, "You cannot throw that away. This is just so super useful." And so we

kept taking it from event to event. And over time it became really like we heard in the introduction, sort of a digital twin for regattas that combines the three major elements, the tracking system with wind data and GPS data, live ranking and scoring, which is super complicated because each sailing event can have different formats and different scoring rules, and then the race management support for official information

such as disqualifications and the official finish results. Just looking at a few highlights. And don't get too confused about the dates here. 2010, yes, SAP was an official sponsor of the 505 uh boat class already because probably Hasso Plattner, one of the co-founders of SAP, was an avid 505 sailor at the time. Very interesting class. We were title sponsor all the way through 2019. Starting 2012, the

solution was deployed live at these events. They have a super complicated, very proprietary gate start, and they have these huge fleets with up to 200 boats racing in one race. So logistically and also from the workloads that we saw on our on our systems, quite challenging. Then our home turf environment, Kieler Woche, it is a super complex event racing on up to 10 race course areas concurrently

uh with dozens of of boat classes. So a mixed multipart, multi-class event. Then 2012, we embarked on maybe a precursor of what then became the SailGP later on, the Extreme Sailing Series. First 40-ft catamarans, then later 32-ft catamarans foiling, the GC32. We were the team that we sponsored, and we sponsored the series throughout. And it was interesting to see how that became a digital transformation in that

particular part of the sport. They were on cardboard and Velcro. That was what they used for scoreboards. So, they actually after each race Velcroed the numbers to a big board. And we replaced that by screens that we could place all over the venue. Uh so, that was quite useful. Again, some challenges with the formats. They use high point scoring where all the other sailing regattas in the

world use low point scoring. And they do weird formats with night races where they split the fleets. Complicated stuff. 2013 gave rise to a new format in sailing, Sailing League. I think that was one of the greatest inventions ever uh because it has national sailing leagues where 18 clubs typically, remember Bundesliga, compete against each other. So, now the clubs are the focus of the attention, which is

super nice uh because the clubs give the infrastructure for all these sailors. The boats are provisioned. Um also from a sustainability point of view, quite an interesting thing. And now the challenge becomes creating a fair pairing list where the 18 teams get assigned to these six boats to run fair races in a round-robin style. So, that also became a new requirement to the solution. Travemünder Woche, very

similar to Kieler Woche. We did that for 6 years in a row. Uh also big multi-class events, super nicely integrated into that uh festival uh that happens every year at the Travemünde beach. Then a bunch of really high-class events, World Cups and uh World Sailing Championships in all the Olympic classes. Most of them work as qualification to the Olympic Games. Which then finally brings us to Tokyo

2020/21. You remember there was some strange pandemic going on at the time. And then 2024 Paris, or should I say Marseille, where the actual sailing regattas happened. That came with very special technical requirements, multi-region scale out. So, we deployed that to five AWS regions High availability, of course, and an interesting setup where the organizers required us to run all the primary environments locally on site. So, at

the Olympics you always have to assume terror attacks, people ripping cables and stuff, and still you have to keep running. That all had to be in an autonomous mode and replication into the cloud was just an option. Gladly, the formats at the Olympics are quite systematic, no split fleets, simple scoring. October 2025, after probably 18 months of internal legal battles, we finally got permission to publish the

whole thing under the Apache 2.0 license, and you know better than we what that means. We made branding configurable, so you can have it your own way. It could even be the Oracle Sailing Analytics now. And yeah, we still do own the SAPSailing.com domain. And yes, there is a subscription program, and subscription fees go straight into the maintenance and support of the companion apps that are also

part of that mono repo as and under the same Apache license as open source. This is how the repository in of lines of code evolved. Very typical chart I would say. So, you see a lot of progress in the beginning and then things harden out. You get some inertia, you get some friction. And of course, when you work from event to event and the events don't wait,

you have to ship, you have to be ready at the event. There is always that issue of architectural depth and the question of how much can you clean up after yourself. You see there's two interesting bumps in that chart. The one strange flat line, that was when we worked hard for a long time to introduce good role-based access management with fine-grained permissions. And then the second bump

there to the right, that is when we finally got into automating our AWS infrastructure and added quite a significant component for landscape automation. Since we published, there have been a few pull requests coming in and merged already. So, we see that it starts working. Um For example, people started adding uh their own boat classes. We We thought we saw it all. 160 different boat classes in the

repo already, but no. Sailing is a very heterogeneous uh sport that has all sorts of things. So, people add boat classes and then another thing that I was super happy about, uh the uh the the head developer of our good partner Track Track um made a pull where the latest new version of their API was integrated with. Up to that point, we always had to do that

ourselves. He's super He's super much in love of the fact that we finally open-sourced the whole thing, made that contribution. I think that's how things should work. And since last week, believe it or not, we're in Eclipse project. Woo! Of course, there's major benefits as all of you know, so that's preaching to the choir. We're hoping to finally move our build pipelines especially for the companion apps

and deploy pipelines over to the Eclipse side so that everybody who makes a contribution and every committer on the project can run these deployment pipelines. But as most of you would probably also know, there's of course some work to do. If you have your initial contribution sitting in some other GitHub repo and you want to move that over questions like how do we migrate package names? our

good old Bugzilla that we still have running with I don't know 7,000 issues out of which more than a thousand are still open. How do we make that GitHub issues migration happen? Thanks to Fred Ger by the way for supporting us in that sometimes quite painful process. So anybody who has a good idea of how to migrate 6000 6500 7000 Bugzilla issues to GitHub issues without losing

dependencies, attachments, timestamps on comments and when it was created, porting the accounts over to GitHub accounts, let me know, write me an email. And most of it come to the both session tonight. So 7:30 in the Riverside area room R3. I'll be there if anyone wants to join, wants to see the system in action, take a glimpse at the repo, look at the architecture, please come by.

We'll have an informal conversation and can can get our hands dirty, run some Docker containers on your laptop with the Sailing Analytics on it. Yeah, get in touch. Probably too tiny to take a photograph, look at the recording, get the slides. Um There's the repo, there's the landing page sap.sailing.com if you want to play around and see what we have in stock.