Welcome to one more episode of Radar Contact. Today we'll speak a lot about software and standardization and quality and air traffic management. And for this, my guest is Christian Woborsky and serves as Product Manager One Control at ADB Safegate. Christian, welcome to Radar Contact.
Hello Vincent. Pleasure to be here. Thank you for having me.
Pleasure to have you. Before we go in the topic, can you just please introduce yourself to our audience, your career so far, and just say a few words about what your current job with ADB Safegate is?
Yep, sure. I basically started my career completely outside of this area as a software engineer writing some banking software, but then soon I joined Austro Control as an air traffic control trainee and always keen to work at airport to see aircraft and so I did everything to come to the tower, which worked and then it went pretty fast and a lot of nice things happened already. Quite soon I was allowed to work as instructor for a simulator and then OJT and then the next step was also quite quick with 29 I applied for the function of head of tower and as I say 29, you can imagine that this was pretty early. There were a lot of other people trying to do this. I was quite far the youngest, but then they took me what I think says also a lot about the culture and the company like Austro Control being allowed to work for something like this.
A lot of learning as you can imagine, especially with this age when former instructors are suddenly now your team members. But it worked. I had my learnings over time. I had been done further promoted being also responsible for the aeronautical reporting office and then later for Vienna approach throughout the years then there was a lot of, let's say, significant steps. I was responsible for the new tower project from the operational side as well as for the new runway project, which is still on hold mainly because of COVID. Later then I learned to fly just small things, worked as a quality manager flight operation in a small companie with just a couple of MD-80s and business jets. Then I went to university twice, first studied aviation management and then years later, law and cooperation actually with ADB Safegate started when we moved in Vienna from paper strips to electronic flight strips as head of Tower this was one of my tasks. And after this we came to the conclusion that having controller with real experience in a project can be helpful and I have been asked if I could cooperate and on future projects, I guess it was Talinn was the first outside of Austria and this cooperation stayed and for many years with various projects basically all over the world. And this is what I still now do support ADB Safegate for various things and especially ground control.
Wow, that's really nice. Lot of operational expertise in different parts here. Thank you very much for the brief intro. So ADB Safegate is coming from airfield lighting, originally doing airfield lighting, then docking systems and the company grew by acquisition. You mentioned electronic strips. The people being in industry for more than five to 10 years will probably remember Avibit, who has been taken over by a Safegate as well. Can you just give us a short overview where the companies come from and where ADB Safegate stands now?
Sure. The company actually is pretty old. I mean ADB has been founded something like 100 years ago, which is quite long while and soon became then a market leader in airfield lighting. Safegate, the other company has also been strong in airfield ground lighting and definitely technology leader in docking systems as you said, Avibit. Now the Graz office has been founded in 2001 and then later on has been acquired by Safegate in 2010 and the whole thing became than one company in 2016 by a merger and also the name, it's where the name is coming from ADB Safegate. Since then there happened a couple of other acquisitions with the focus of expanding in existing market and of course also to extend the portfolio like airport systems, data systems. And the result, what we see now is then definitely a kind of unique portfolio with a really integrated value proposition covering the basically entire airport operation. And all this can be seen as an enabler for our holistic airside vision.
So you are serving airports and ANSPs now starting from AGL up to systems for towers. Can you quickly bring us through all the offering you have starting with AGL and maybe ending with ATM systems?
Yeah, sure. Basically, as you know, this airfield and docking business is more a commodity business. There's a highly competitive environment and with this acquisition of Avibit, as I said something like 17 years ago, the company started to integrate ATM systems and that's a big difference between, let's see, apron controls operated by airports or ground control control operated by ANSPs. But the goal was and still is a combination of intelligent airfield solutions with ATM systems. And examples are, for example the combination of AGL and routing and guidance function, which is more on the software part or using docking guidance systems as additional surveillance sensors. And this is what you can do in-house when you accommodate the entire portfolio. The tower business line itself designs and develops integrated software solution for, as I said, air traffic controllers, apron controllers. For me personally, there's no difference, but sometimes it's kept separately integrated controller working positions like one control with a high level of support by automation, but still on the other side or on the other end., also, traditional solutions like A-SMGCS and e-strips demand all be the option to upgrade in the future so that every customer can choose whatever fits at a very given moment in time. And what has always been driving us is to have a deep understanding of operational constraints and of course not just the constraints only, but how to address them. And the result is what you can see them is that the systems like being complex in the background are quite easy to handle. This makes the operation safe and the factor of which should not be overlooked is that the training costs can be kept low. Examples for these things of combining all these areas is the evolution of adaptive flights with OneControl, which are just now being rolled out or on the other side, smart sensors out there in the airfield, in the ground lighting which are collecting data and feeding them back in real time in the airport or ANSP systems.
You said something that's marked me a bit in what you said. You say you make no difference between apron controllers and ground controllers in the tower in term of work, fully agree with that, but in term of organization there is a big difference here and I've seen that in several A-SMGCS projects. Often the A-SMGCS is part of the lighting system which typically belongs to the airport and is paid for by the airport, but the user is also the controllers in the tower, which used to be ANSP. Have you seen this kind of difficulties of having someone paying for the system and someone else using it or is it integrated enough that you overcome these things?
The answer is yes and no at the same time. Yes, we see these things and they go way further than that. It's sometimes way more complicated than just who pays the system. It's also how people are working, what kind of contracts they have, what kind of, let's say unofficial hierarchy exists there and other things like this. But as we are solution focused, we see the system as enablers for operations and who the owner, then is who is paying for the thing, who is part of configuring is just a side effect, let's call it like this. The main goal is always that the system has to support or the systems have to support the people working there. And if they are called apron controllers or ATC ground controllers, whoever is, as I said, it's a side effect, but the main focus is always on the functionality of the system.
Thank you. Now going a bit deeper to the topic we want to address today, which is standardization. Looking at ATM software, especially from the financial perspective, it's stupidly expensive and there are reasons for that. I mean it's software that is made for a very small market. It's not like mainstream software where you can have millions of customers. I mean if you look at the A-SMGCS, there are probably not even 5,000 airports in the world that would need an A-SMGCS, then you have the safety aspect that make the development process a bit more expensive than let's say standards general public software. But I think a factor that is at play as well is the way ATC is being done. I mean, okay, we all work according to ICAO regulations. The rules are the same all over the world, but nevertheless every unit works slightly differently and people have their habits, people have specificities, you have special rules, a bit all over the place and this sometimes make some software hards, I used to say in the total cost of any ATM system, at least 20% extra is for local adaptation, be it interface, two special systems be it, changes for local procedures.
Do you think with standardization we can bring the price lower or do you think we are as low as we can for now?
Let me start with my own experience. When I was just on the receiving side as a customer at the beginning of all these things, when we moved away from paper strips, when the A-SMGCS were coming up, honestly I didn't care at all about standardization. There was the responsibility for Vienna and also then for the other airports in Austria. And all what I had in my head as a customer is I want to have this like this and what anybody else does. it was completely unimportant back then for me. This has obviously changed and this is what I guess you can see also there everywhere and the mixture of having a standardization and customization is without any alternative. As you said, there are different procedures for various reasons and whenever you go anywhere to a customer, they will not just because of our product, and this applies to our competitors as well, just change all the procedures.
Sometimes they just can't, based on legal requirements, based on topography, based on how the airport is built. So this customization while we try to keep it low, is always needed. So what we talk with customers is to find the right way in the middle. And what we have seen also that customers more and more are interested to having a standardized product. Why? They want to be in line with update paths. They look on a costs as you said, and so there is no alternative then to find anywhere a way in the middle. How do we do this? It's just to make the software flexible to have something which is a core function. And whenever we implement something specifically for an airport, we see if this is something what should become part of a standardized project, standardized product, or if this is something that has to be configurable, be it color, speed sizes being routing rules.
So all these things over time get more and more configurable. And this is then also reflected on future projects in terms of costs. Because when something is configurable already, then the software comes with this flexibility to say, yes, okay, you do it in a different way than we have seen it before, but doesn't matter. We solve this by configuration. Still it's a task of course it has to be defined, it has to be done, it has to be tested and documented, but there is no other way around to avoid exactly what you said, that costs are exploding. Nobody would be willing to pay for this. And it's from my point of view also a definition of quality of software. Not only what it does, but at the same time how easily it can be adapted. And it's not only from site to site. Think about airport extensions, think about rule changings. I mean I've seen so many changes in regulations and norms and laws over the decades that the software has to also grow with you even onsite. You need this configurability. And as I said, this is one of the markers of a, let's call it maybe a KPI, how easily and flexible a software product can be configured. So as then at the end, it's still a standardized product but it has some configuration options and this is what we're doing and this is from my point of view, the only possible option.
Do you think your personal background as the air traffic controller helps you making decision and discussing with users there? Because I mean air traffic controllers think and perceive things sometimes in a way that is a bit different. And I've been myself in meetings with air traffic controllers and it's sometimes hard when air traffic controllers come with requests and say, I absolutely need that thing to be my way to be configurable because otherwise it's a safety issue. And to be honest, sometimes that goes a bit too far in my view. And do you think yourself being an ex air traffic controller helps you making the decisions there?
Absolutely agree with what you say. Have seen it by myself lots and lots of times. But this is just one side of the coin. What you are describing is something that can be seen as a problem. Okay, let's leave it like it is. But what is way more interesting is how to handle these things then. And this is why we, first of all, when we start a project, wherever we go, we address this very issue. Say, look, there's change coming now. How will be the reaction? What is the mindset of the people? What is the history of modifications? How is the entire change management process done in a company? And I strongly believe that when you involve users from day one and actively address this issue, then it's not a solution yet of course, but it's already appreciation of their concerns. There are various reasons why users, controllers in this case, will react in this way.
And I don't think that this is something that is specific for controllers. Pilots are very similar. My mother-in-law is a medical doctor, she works in a hospital, very similar patterns there. It's just that you rely on an environment because you trust on this environment. And if you wake up a pilot, a doctor, a controller at three o'clock in the morning and ask for some procedure, some HMI thing, they just know it by heart. And then somebody comes and changes all this and this always creates the feeling of uncertainty. Maybe doubt, will I be able to handle it? What will the system do? Maybe also being scared of talking about some are just scared of admitting that they're scared but there's nothing wrong on it. And when we actively address this and I share my own experience, how I have seen these things, what I've learned on the other side, then it's already the first step is done.
Does this solve everything? Of course, not that no one fits all solution, but it's at least a starting point. And then when you are already within the discussions of controllers and share your experience, and not only my personal as controller, but please keep in mind when we go from one place to the other, we always learn something. I mean we implemented systems from Nepal to Columbia to Germany, UK, UAE, and there's a lot of different cultures and you always also take something of course come, we share experience, but always when we finish something then we take something with us and whenever we go into a new project, we just put this on the table in a really open and not judgemental way to say, look guys, this is what I have seen there, this is what I've seen there. What do you think about it?
And once you achieve this discussion, it's more than halfway done already. And again, as I said it before, does it solve everything? No, this is just not possible. And once in a while, then the customer has to make a decision. And when you ask 50 controllers, of course you will get different opinions. What fits fine for one is maybe unacceptable for others. But I guess this is quite unique and common thing. And if all these things will not lead to a joint understanding to an agreement, then ultimately the customer will have to make a decision. I mean we are just sharing experience. We come with proposals, we listen to the controllers, we learn about the way how they work to feed the pain points. We come with proposals, but then it's up to the customer to make a final decision. And this is where we can just as always, be let's say advisors.
That's a great approach. I like it a lot. And now to put a more positive light on controllers, there are always some that want to push you a bit more, that want a bit more innovation, a bit more automation, a bit more advanced systems. And I guess you face up these ones as well and it's probably pushing you a bit sometimes further than you want to, right?
I never feel pushed by something like this. And as you said, a more positive light, I wouldn't call this what I just explained before, not positive. I think it's quite natural and it's also needed. I have full understanding for these things we have to take people from where they are. So I don't see anything negative on this. And yes, you have a lot of different personalities from very conservative to extremely futuristic. And also here it's a learning process because when somebody comes up and has a great idea, then I would just say, I shamelessly steal this idea and say, Hey, that's fine, take it with me. But besides of configuring a system and developing something, of course we always have to have a look on the entire project, not everything what is technically possible is worth to pay for, even if this sounds hard. And sometimes you come up or somebody comes up with an idea and said, wouldn't it be great if the system could do this and this say, yeah, it's definitely a good idea, but the costs are extremely high to do it or the frequency of using this function is so pretty low that this balancing is just not there.
And I had been, there's quite a lot of air traffic controllers in Austria and when I've done this, many came up and said, would it be fine if the software could do this and this that, yes, I see. But we always have to have an eye on the costs of this something. We have to have this efficiency. It's not like Christmas where we can wish everything. And also this is nothing bad. And very often, I guess you would be surprised when you explain this in a proper way, talk with people. Say, look, this function is something but is nice, no discussion, but it costs, I don't know, 10,000, 15,000 euros and you will use it three times a month. And there would be also an option B, C and D, what do you think about this? And very often people then say, oh yeah, I see, okay, it's nice, but yeah, it's just too expensive or not worthwhile.
Or sometimes ideas have just negative effects on the other end and you cannot expect from controllers, definitely not that they have system-wide understanding. It's not their job. Their job is to use the systems and have basic understanding how the system works, but it's not their job to design systems. It's not something what you just get automatically when you get your air traffic controller license. This is not there. But also these things, most of them can be solved by reasonable discussion. It might sound time consuming at the beginning, but it's a very, very well done investment because it comes back multiplied then at the end when you implement the system because people then just much, much more easier take it as their own system and not just somebody is coming and putting in there and say, okay, this is what you use now. They're just really making it their system and they see why things have been done, but they also understand why things have not been done. And this is at least as the same importance.
We are now reaching a time where you not only deploy new systems, but we reach a point in history where A-SMGCS are in the second or third generation, flight strips the same thing. And I know you've been through cases where you replaced the system with your system and the previous system was not developed by anybody but homemade, so developed by the ANSP and because of that very, very tightly knit and tailor made for the operation, is that a different replacement case for you? Is it something specific or can you handle it with the same approach
There's no, or you made a lot of comments. First question, is there a difference? Yes, there is a difference, absolutely. And there is a difference in the area of customization. As you said, when an ANSP or also an airport is developing a system by themselves, then it's highly customized. This is one thing, but there is a second thing as well. I guess what we must not forget is there are people standing behind such a system and they have invested years or maybe decades of times of thinking of coming up with solutions and suddenly all their work is going to be gone or lost or unimportant and you come up then and say, okay, let's do it in a different way because this is all. So in such a situation it's even more important to really take people from where they are and have respect of what they have done.
But also this is not new for us. We have seen this a couple of times. It's a new AODB, it's a new strip system, it doesn't matter basically what it is and most of the time when they move away from a homemade or self-developed system, there's also a reason for this. So people are not surprised that this is going to happen, but still, there's also sometimes, and this is what you will not find in an Excel sheet or in a cost calculation, there's also these human factors in there. People they identify themselves by the work they have done. So yes, it's a specific case, but the approach is, I would say the same because it's driven by respect, by being humble and never forget what we are and who we are. We are supporters, we provide systems which are enablers. The focus is still on what these people do and I guess this mean there's always exceptions and we can't solve everything, but basically I would say this works there as well.
I really like the way you put the people in front and first and the system, as you said, you are supporters and I think a lot of this change has to do with expectations and change management. Now looking at your recent experience in Europe specifically, you have a project almost completed at Frankfurt Airport and I mean it's my home airport for me and Frankfurt is by far not the simplest airport you can imagine. It grew up historically, it's quite close to the city. You have runways that are used only for departures, only for landings, there are three apron control towers with a fourth one coming in the south. So it's definitely not the easiest airport ever. So where do you stand there? What is the status of your project and can you tell us a bit more about it?
Yeah, you described it quite well already. I would say it runs very well now and when I say it runs very well now, then you can of course sense that it has not always been like this. It is really a very complex environment both on the layout of the airport, which is just anything else than ideal. Nobody would build an airport like this now. Also from the procedure side, from organizational structures, from institutions who have a say in thing, it is definitely quite complex and it was also a learning lesson for us. No, there it's huge and there have been some ups and downs, but we always have had to focus on this common target and this common commitment then finally brought us where we are and I'm pretty much satisfied now. The final software version has been delivered already and it's now running on the simulator and also in live operation to have something like a shadow operation to see over time how it works with real data and they are doing their training. And I mean that there's something what maybe is also a sign for this, which just that the recent expo in Geneva, we signed a multi-year partnership agreement with Fraport to continue to develop this and I would be, let's say brave and say in case Frankfurt was not satisfied with what we do, they just would not do it.
So there were some ups and downs, lots of learning, but it's pretty much doing well. I'm very much satisfied now. When I talk about complexity, you mentioned just a few things, but something else that OneControl has this routing function in and also already guidance in parts of the airport and they have for example, a lot of different routing systems, so depending on the runway where they guide aircraft always into the east or the west no better where they go and then make a 180 and go back based on the lack of space they have. When you change to other visibility options, they have to change their rooting completely. When there is CAT II, CAT III operation, there is again a different standard and what is very interesting, and I guess OneControl really grew on this is they have lots of deviations from their standards and these deviations are standardized again.
Okay, basically the aircraft always has to go there via taxi Lima, but when it lands on this runway and when the traffic is doing this and this, then I would like the system to propose a routing via November and November 8, et cetera, et cetera. So there is something like standardized deviations and this made it again complex, but this is what you can see also from a very positive side, it's a challenge because the task is to have this complexity in the background invisible for the user because the user is not interested in algorithms and questions and this is unimportant. What the user expects is that in every situation the system is behaving like she or he would just expect have it like this and it just made us better I would say like this and not only for Frankfurt, but it's again a learning lesson also for other current customers we have.
So whatever we learn in Frankfurt, we share also with other customers, current ones and also for future customers. This just made the product so much better and when I look in this then we are just grateful for these challenges. It has not always been easy. Yes, sometimes you just scratch your head and say, Jesus, how are we going to solve this and why this not coming up again, we talked about this and I thought that was solved again. But if you then look back, you can say, I just thanks for giving a chance to do something like this for an airport, which is pretty important in Europe. And I mainly have a running joke in within house. You say, as somebody who can master Frankfurt can master everything.
I would tend to agree with that. And just to stress out what you said about sharing that experience ,does it means if you develop a new functionality for let's say Frankfurt, but anywhere your other customers can benefit from it, is your software standardized and to speak a bit in software development language in the same branch enough or is it hard for you to retrofit something learned at airport A to airport B?
No, it's not hard anymore. This has been hard in the past, but at the moment there's just one OneControl existing and if it's a Hamburg OneControl or a Frankfurt OneControl, it is the same system. We cannot afford to have multiple various branches to have different systems. This is not what we are doing. There is just one software package and whatever needs to be configured is configurable.
Wow, that's pretty impressive from the software development part. Now to finish, we have our standard question, who do you see ATM and ATM systems in five years from now? And also to open the door to more flexibility and fantasies, where do you see ATM system in 50 years?
I guess there will be some changes around in the next five years, mainly driven from the environmental side. This is something what was visible already for, I don't know, almost 10 years and the pressure on operation, and this means also then on systems will be higher on efficiency, be it continuous descent approaches, having more efficient taxi times supported by system conflict display. When you see there's an aircraft on a parking stand, the next one is coming in to give in time information to the controller. Hey, there's an overlap. Things like this where you can be more flexible. This is definitely something what I expect and there's something else. What we do in house, we do have some, let's say two major projects that will have a significant impact on how controllers work at airports and around the airports. And I'm talking big here and I'm very optimistic that we will put this on the market within this five year period and there will be some change.
I guess you don't want to say more right now, right? About what these two changes are?
No, it's a bit early, I can't. Just what I can say is it'll have a very positive impact on safety,of operation, on efficiency and it'll have a strong impact on the workload of controllers.
Well, I guess we'll all keep our eyes on ADB Safegate. And now to finish, how do you see the 50 years from now?
Yeah, that's an easy question for me because chances are quite low that I will be still around in 50 years, not so I can't say no there was a lesson. Nobody can prove me, right or wrong as I will not be here anymore. No, I guess there are some indications already now. Autonomous transportation will be much more developed as it's now hard to say how far as this is not only a technical issue, I'm sure you followed up the discussions about the single man cockpit, let alone about having aircraft without pilots. So it's not so much a question if this will be done technically. I mean it is possible already, but how much it'll be accepted by societies. People have no problem anymore to go into a train at the airport and go by just from one terminal to the other. Nobody is there. Difficult to say how far this will go and when it comes to them to the role of operators, I see a strong change there.
I guess the role of controllers will really continue to change in what is visible right now. Already there will be more, I wouldn't say administrators, this sounds a bit, I don't know this, don't like this so much, but I guess the task will change is that they are more monitoring and seeing what systems are done, what artificial intelligence is doing, what algorithms are doing, and then they will just step in when it's needed. They will have much, much better in-time data and will have much better tools to make their decision process supported. This is basically how I see it. I still see people somehow in the center, but in a much changed function role.
Christian, thank you for sharing your views both on project and on the future. It was really interesting lot of experience here, so thank you very much for that and I hope to talk with you again soon.
Thank you. Pleasure is on my side.
