Vancouver 2010 – Is CAATS ready to entering the mountains?

[Michael YVR]

That has been a long run since John Crichton, the Nav Canada ‘s CEO, told to the Air Traffic Control Association, in Vancouver, June 8, 2000:

You could say that we’ve finally "got the CAATS by the tail" .

What is the CAATS response: “You should have seen the head of the other guys”?

That’s not very good for the image.

Tailing that head, controllers have already entered the walls.

Do the maths:

• Frozen system specifications until delivery + Altered architectural design since delivery =>
  • { Permanent damages: (like altered functionalities & lower system performance) AND
    Safety risks: (like saturation, instability, breakdown) }

For sure, April 30 2007, the Montreal ACC’s CAATS breakdown didn’t fit the safety picture.

Since no progress was made.

Testing the operational readiness prior a new ACC installation is not exactly what should be call a progress. That’s pure simulation. As a long overdue caution that is probably good enough for the controller to fool themselves, but not an excuse to fool others.

Testing is weak about safety.

Requesting Descent. (in Westjet forum)
“Only thing I can say is that it has caused a separation issue (not a loss, but an uncomfortable situation before.”

“I have to admit that at least 95% of your flights that I've worked don't seem to have this problem, but there are still an odd few, and of those few there is a very small percentage where safety has the potential to be affected.”

“For the record, CAATS our new system does loosely predict where you will start descent based on”
A/C Type, and the flight level that has been put in the machine (Does not re-calculate for intermediate altitudes unless the system is manually updated.)
It is not very useful at the moment, as it is only a predicted guess that factors the winds and a/c type, and in order to display it creates more work than just asking.”

Beyond simulations, there are the air traffic control operations.
Therefore, about accountability and responsibilities, Nav Canada has not the right to remain silent. All what John Crichton will not say shall be retained against him.
I know the Nav Canada's CAATS engineering team has always been a lot overwhelm: no accurate tool support, no adequate training, no efficient development process, not being listening.

In facts, when the staging of activities is poorly defined, managers have an extremely difficult time establishing the status of the project's progress and activities.
Without process visibility, managers are not able to estimate and then track quantitatively the impact and effectiveness of change.
Inefficient or defect-prone activities can’t be identified, replaced or revised

It was not like that, during the CAATS development in Richmond, BC:
- DVM (Distributed Virtual Machine): 1993 - 1996+
- ATC Domain Architecture: 1995 - 1998+
- Delivered to Nav Canada: October 2000

The good new is: since October 2000 the DVM has not being yet altered.

• A chance it could help to make the non-ATC concerns transparent to ATC applications.
  And the architecture was made to enforce Reliability/Availability (Fault Tolerance), Efficiency, Scalability, ...

About safety, that is not about reliability, but about anything else.

To make a safe and reliable solution is call an “emergency”, to promptly get one solution is call to “take a chance”.

Some engineering lines about the CAATS emergency:

• An independent system safety assessment is necessary and mandatory
  In parallel, a functional system reliability and vulnerability analysis is required
  To establishing what the current status is:
• Analysis of the deficiencies, of the motivations for the decisions made, of the implemented solution and the resulting effects on the system.
• Ditto, about new functionalities that were upgraded or customised according to the ACC specific operations.

• Analysis of the impact of switching from the transitional mode (on effect until all ACC commissioning is completed), to the full operational mode.

Unlless you would prefer we take chance.
In Vancouver, like CAATS, athletes are going to be stretched beyond their limits?
You can wish all of them a “good luck”, but no one should break a leg.

[invertedattitude]

Not sure the point of this post except to bash CAATS?

Yes it has its problems, there is no doubt, and still experiences setbacks, but they are fewer and farther between.

The functionaltiy for displaying an aircrafts estimated descent point is not that difficult to use, unless you're one handed or something, all you do is use the mouse, that being said I don't see the point to using it.

If there's traffic, then do ATC, if not then issue a PD descent. (When Ready whatever..)

[cyvr_2010]

Not sure the point of this post except to bash CAATS?

Yes it has its problems, there is no doubt, and still experiences setbacks, but they are fewer and farther between.

The functionaltiy for displaying an aircrafts estimated descent point is not that difficult to use, unless you're one handed or something, all you do is use the mouse, that being said I don't see the point to using it.

If there's traffic, then do ATC, if not then issue a PD descent. (When Ready whatever..)

Spoken like a true novice who obviously has never seen or used a decent radar system

[Michael YVR]

The point is the above engineering lines about the CAATS emergency.

That should oblige Nav Canada to start behaving like any responsible Air Traffic System service provider across the world.

CAATS, which Nav Canada has such difficulty to implement across Canada, is an infrastructure whose latent deficiency and architecture design problem might cause ´unexpected´ safety issues during the next winter games in Vancouver.

After the CAATS complete breakdown within the whole Montreal Area Control Center, April 30 2007, the Nav Canada engineering incapability is a subject the Nav Canada’s CEO is non longer eager to deny. (But he has not the right to remain silent. Every thing he won’t say shall be retained against him).

The Montreal air traffic controllers get surprised, but they had accurate flight strips so they could start juggling with the flights. (The risks a problem will occur were quite obvious in Montreal, so the controllers remained particularly awake these days.)

About next winter in Vancouver, risks are not that obvious, so any consequence might be more random, depending on the controllers’ vigilance and how messy or critical could be a situation.

The problems are not within the Vancouver area only but in the coordination of the whole Canadian airspace.
By successively announcing the completion of the remaining area control center(s) by 2006, 2008, August 2009, and now by the end of calendar 2009, Nav Canada has raised a safety issue:

What else happened which has suddenly required to postponing the CAATS completion in such a low profile manner?

Now we get a lost of separation between two safety critical events. Thanks for the overlap. The CAATS pan Canadian "completion" could not happen at a worst time.

(“Safety is not all about failures. This erroneous belief is rooted in the lack of a systemic approach. The absence of equipment failure cannot be equated to the absence of hazard. Conversely, the deviations from nominal conditions are not inherently unsafe and the limits up to which safety is preserved can be a field of research.” - CAATS Brussels)

Nav Canada only started considering the CAATS deficiency as a problem after the CAATS Montreal breakdown - April 30 2007. Operations Strategic Plan 2008–2011 “To address CAATS deficiencies and set priorities for the required corrective actions".

As a result of the frozen system specifications and of the altered architectural design:

• A lot of adjustments were made to compensate the consequent deficiencies.
• To avoid hurdle, most deficiencies were compensated into the context they were occurring.

As a result of the non-mature software development process:

• Too many errors have been introduced within the software,
• Some errors have been corrected by others errors,
• Within the operational domain that has been exercised, a few errors can have mutual self-correcting effect.
• It is current to see a temporary system correction hinging upon another,
• It is current to see new improvements being scattered across the different architectural levels.

As a result of the functional variances across 7 centres,

• The operational domain constraints went beyond the system designed capabilities
• The system becomes a hurdle to tussle with

As a result of all of the above:

• Deficiencies might hardly linger
• The system can falter

As a result of the Nav Canada engineering incapacity and lack of maturity, CAATS currently is a chaos which is hardly to converge to a compliant and safe expectation.

What next?

• Will there ever have enough sufficient evidence, to convincing Nav Canada to resign from its engineering incapacity?
• Will the Canadian Government keep itself forever busy in what can be done to get a situation worst?

(Last fall, when any status report went under control of the Treasury Board of Canada Secretariat, any flak the Canadian Defence wrote about CAATS was “removed” from the 2006-2007 Status Report on Major Crown Projects.)

From complacency and make-up to breakdown… there is like a criminal negligence atmosphere in suspense…

[pokaroo]

what is your background? are you a controller?

[killer84]

I can say with certainty that he is not an English teacher...

[IFRATC]

Is it me or is this thread in a language I can't fathom? WTF. Secondly, if their is a point to it, I can't discern a F*$KING thesis or extrapilate a conclusion whatsoever! HELP.

IFRATC

[Michael YVR]

I’m engineer in BC, and have a software development background for airspace and military applications like CAATS and MAATS. Until 2006 I was focusing on determining the CAATS system vulnerability to early identify any sign of anomalies and removing deficiencies.
Therefore I could measure the CAATS divergences: increasing deficiencies, inaccurate problems solving: and its consequences in regard of safety, instability and saturation of both CAATS/MAATS systems.

At this time NavCanada was still trying to assume the MAATS/CAATS integration and completion. Which, in 2007, leads to the MAATS cancelation, like suggested by the 2006-2007 National Defence’s status report:
“Since accepting the Canadian Automated Air Traffic System (CAATS) from Raytheon Canada, NavCanada has independently continued system development and deployment. Their schedule has suffered numerous setbacks and, to date, only the Moncton Area Control Centre has been converted to CAATS. NavCanada has set an aggressive schedule extending into 2008 for the remaining six implementations. The Military Automated Air Traffic System (MAATS) is encountering many of the same system deficiencies that have slowed CAATS implementation. Correction of these deficiencies and the need to re-establish interoperability between the two products after many years of divergence has significantly delayed MAATS implementation and increased project risk.”
English is better, but not what its means.

Initially, the Nav Canada upper-management conviction that CAATS didn't need a better defined engineering development process approach, was comforted by the difficulties Raytheon has encountered during the CAATS development final phase – (CAATS maintenance was going to Ottawa, a lot of international engineers went back to their country).

For almost 10 years, NavCanada should have got a few doubts, but after the April 30, 2007 Montreal breakdown, the Transport Canada response to engineers was as “NavCanada is in charge, such incident doesn’t matter” – May 17, 2007.

NavCanada is almost correcting CAATS errors with other errors, until such error will apparently no longer matters or the controllers would handle that error via another special procedure.

That way the CAATS system seems to work, but keeps defying all the laws of the logic, until the operational context limitations and constraints will make CAATS to improvise.

In 2005 an error more serious than any other ones before, has occurred: (it caused a flight strip to be sent back to Gander: a controllers’ concern, since flight strips are to be used as a backup in case of system deficiency or breakdown). Such error has never being resolved but covered by a side effect. It still can be triggered by a manual controller command, unlikely to be made within a specific 30 seconds window, on a specific flight profile, within specific ACC configuration data.

An independent system safety assessment and a functional system reliability and vulnerability analysis should identify a solution. Not only for that problem, but all the incoherencies this problem has accidentally disclosed.
Incoherencies which are inherent to software development procedures conceived for small, non-complex projects - in comparison with CAATS – Incoherencies which have also promoted a few controllers as CAATS system designer to initiating the worst design error ever made in CAATS.

Indeed, such design could have made sense, but not within the new NavCanada CAATS architectural modification – here was a problem: NavCanada didn't understand what they were doing!
Don’t ask why NavCanada still remain silent. Je donne ma langue au chat.

“We all know that Build cut corners - the schedule came first at the expense of the Engineering / Quality / call it what you will. Many people (including myself) were uncomfortable with this, but it served an important purpose at the time. That time is past. We have recently spent significant effort in reinvigorating process, procedure and standard. We are not finished with the activity, but we have made great strides and will continue to push. Going forward, we must follow these procedure and documents. If we can't follow them, we need to have a discussion and record the concession, along with the risks we are consequently carrying and the plan to work off (ie remove) the concession.

Even outside of the procedure and standard documentation, everyone on this project knows when they are doing something that feels wrong. Working to un-reviewed draft documents; rushing reviews; working with procedures not in place yet(!)."

I need to point out this is not an about-turn with schedule now ignored in favour of Engineering Quality! Like many things in life, there is a balance to be struck. Sometimes we will move the schedule to accommodate a critical engineering activity. Sometimes we will agree an engineering concession in order to keep to schedule. Each case needs to be judged on its unique merits. The level that this discussion is held also matters……”

English is definitely much better. But engineering is at another level. Here is the divergence. And why CAATS will still make problems. Safety problems - the ones which doesn't matters....

[invertedattitude]

In 2005 an error more serious than any other ones before, has occurred: (it caused a flight strip to be sent back to Gander: a controllers’ concern, since flight strips are to be used as a backup in case of system deficiency or breakdown). Such error has never being resolved but covered by a side effect. It still can be triggered by a manual controller command, unlikely to be made within a specific 30 seconds window, on a specific flight profile, within specific ACC configuration data.

Ok, first... what the hell does "It Caused a flight strip to be sent back to Gander"

WTF does that mean? The Info was sent back to QX? The strip printed backwards for a QX Controller? (Obviously never heard of the Double Headed Monster then) Be a little more specific to what you're talking about?

Flight Strips are used as a backup? Maybe in some terminal units.
While no doubt the stripless enroute envrionment across the country is coming soon in relative terms, it's not here yet.

While I do appreciate your safety concerns, they may be valid and important, your posts are incredibly vague to anyone except perhaps another engineer.

[Michael YVR]

First, that’s not about what a problem can cause, but what can cause a problem, and what can be the impacts.

The difference is about whether or not a system can be safe and reliable.

The flight strip estimate sent in the opposite flight direction is quite no longer a reachable problem, but it must have a solution: i.e.: not a NavCanada priority.

NOTE: Safety issues better hide behind such thing call “no longer a reachable problem”.

So FIRST, controllers should ensure there is such thing call “an independent system safety assessment” on CAATS as well as a “functional system reliability and vulnerability analysis”.[/b]

There is no “stripless enroute environment across the country to coming soon” without that.

So, the last time a controller saw the flight strip problem, what did he say: “It would appear that this is essential to be fixed before Gander can implement”.

Find the semantic error! Problem to be resolved or deficiency to be removed, but nothing to be fixed, this will hardly suggest an improvement.

About the flight strip problem, no one ever had a clue, except it had occurred on a development built.


In facts, all the following accumulated errors had triggered this flight strip problem:
(A): One design error => saturation risk => instability or breakdown.
(B): One algorithm error => propagate some persistent anomalies which can trigger a few behavioural deficiencies
(C): One incomplete specification => hole(s) in the logic, whether you fall into. Can propagate a deficiency or fix one.

With (A), (B) is reachable but was hiding (C): whether (B) or (C) could trigger the flight strip problem.

(B) was removed from a development build at the time (A) was implemented on all the development builds.

So (C) get reachable once and easy reproducible on SIMI – but no clue yet about what specification still incomplete, no even a clue there was an incomplete specification: worst was an option, since there was no trace (anomaly) of an algorithm or logical error.

Gander build got (A) and (C). But (C) didn’t get reached within a real operational context.
A certain time after Gander (A) got removed – it could not stay too long: i.e.: too high saturation risks.

The (A) design error was introduced as a result to compensate the CSiT integration within CAATS (i.e.: “the architectural design alteration since the CAATS delivery”), and to compensate the frozen CAATS specifications - Not much about a bad choice, but not knowing what doing

The (B) and (C) deficiencies were introduced as a result of the CAATS specification being frozen until the CAATS delivery.

The (B) algorithm error was resolved prior any problem had occurred. i.e.: to demonstrate how promptly resolve the common CAATS/MAATS deficiencies.

The (C) incomplete specification is the kind of deficiency to better be resolved on MAATS, since the MAATS specifications extended the CAATS frozen specifications, but in a way the CAATS design was not intended for. (This also means that the CAATS design, made from frozen specifications, was not entirely intended to meet all ATS operational constraints).


Most of the Canada's ANS problems come from the fact NavCanada didn’t favour a collaborative engineering approach with the Canadian Defence. So MAATS get scrapped, and without safety insurance CAATS can’t get better.

CAATS meeting CSiT in geology that should be call an earthquake.
In engineering that has caused more deficiencies, more incoherences, one breakdown, and always more delays to attempting to fix a mess.

(About all the fixes, not quite sure on who got stone!).

CAATS is a chaos which shall never converge to a compliant and safe solution.
The flight strip sent back is one deficiency where almost any kind of problem has converged.
It definitely shows how NavCanada is not ready to large, complex, safety-critical software engineering.

NavCanada will never deny any of the above.
“Engineering and software process are all about theories and abstractions, I don’t need theories, all I need is a good team to work with.” (The VP engineering) Paternalism and compliments didn’t help that much!

CAATS is a real time system which computes and distributes current information one flight and one controller at a time. Not at any time, but periodically enough to process accurate information. CAATS/MAATS are made of abstractions, behavioural, functional, architectural models, approximations, synchronisations, asynchronisations, batch tasking, distributed processing,…

Below is the distributed virtual machine (DVM), all about separation of concerns, reliability, functionality/availability, fault tolerance, efficiency, scalability,
The DVM makes the non-ATC concerns transparent to ATC applications, as if:

• single computer,
• single process,
• single thread,
• etc.

CSiT made CAATS a hybrid system, with hybrid development process, functional incompatibility, constraints and limitations. (i.e..: lost of conflict prediction alert, clearance validation …, and needs for a flight strip backup just in case the lost would suddenly increase), and not yet entirely defined systems specifications.

The Canada's compliance to international safety standards is no longer a matter of choice, the world is coming!

[pokaroo]

If you are that concerned about CAATS, file something with Transport Canada.

I do agree with your point that Navcanada's emphasis does not seem to be about safety. (At least I think that's one of your points) This has become evident lately is numerous aspects of the day to day operation of Air Traffic Control in Canada.

The language in your previous posts do make them very hard to read though, and while I'm sure you have gained some insight into the ATC process your lack of a working knowledge of how CAATS functions in an operational environment does hurt your cause.

I guess my point is.......what's your point??

[invertedattitude]

Seriously Micheal YVR, your posts are very poorly written, and jump from one point to another without resolving anything.

I can only speak to my experience with CAATS but I will make these points:

1.) CAATS has significantly reduced my workload in certain areas, although slightly increased them in others.
2.) I would roughly estimate that only 5% of the time have I seen CAATS experiencing an anomoly which affected my job, but rarely safety (I can control with Splats if I need to, or just with strips in fact I control with strips only on a daily basis in some sectors
3.)CAATS needs improvements in some areas, but with each build it seems to be working better, and more stable. I'm definately not saying its perfect by any means, but the reduction in workload that CAATS has brought is something I'd never want to give up.

Also, if you're concerned NavCanada is not about safety first, but about the money. Well regardless if they are or not, welcome to the world buddy.

Especially the world of Aviation, I've worked for numerous airlines before coming to NavCanada, and not one of those airlines were about safety first, IMO none of them are, they all preach it yes. But it's safety first only if they can't avoid spending the money due to regulation, and then if they are forced to do so, they will praise themselves to the high heavens as if it was their choice. I've never seen an airline go too far above and beyond the regs in terms of safety, although it does happen from time to time, it is a rare thing

Have a read up on some of our FAA brothers and sisters to the south about their take on the FAA's safety stance in regards to ATC...

[Michael YVR]

My point is going ahead with the Air Traffic Control’s point #3 (good nickname).

I’m engineer. My job is to make technology working and being responsible if as a result of what I did, something goes bad.
CAATS/MAATS is one of those things I had work for. Trust me, it worth the efforts.

I figure the controllers would prefer a strong engineering support to listen to operational problems; there shall be better ways to find solutions.
Removing CAATS is not an option.
It happened with MAATS, because the Defence knew that NavCanada will ignore the common CAATS/MAATS deficiencies
– lost $150 millions for the Defence – that's still better than depending on NavCanada improvisation.

The priority is to enhance the CAATS reliabilities as per the engineering process.

If someone were able to understand what I have “very poorly written”, it was about NavCanada juggling with 3 kinds of deficiency at a time: the problem vanished but nothing was changed.
Just a try, but not such nice: i.e.: No one noticed the deficiency was still there, as it was much harder to trigger within the operational context.
("very poorly written" = fire wall against intruders - please avoid)

I would like to believe that after having done all the error being possible to make, CAATS shall be working fine.
(NavCanada made CAATS mostly by tests/errors and mitigated most of the errors which caused problems - removed instead of mitigated when still possible to remove).
That looks quite like an infinite loop.

At the end should CAATS being working fine?
There are still more delays. And you should know what delay means.

Problem is about the software resilience. CAATS was conceived as fault-tolerant but not to such a point.
Indeed the CAATS Raytheon design was not entirely intended to meet all ATS operational constraints,
i.e.: CAATS ATC applications were conceived from the operational specifications that NavCanada had frozen in 1996 - "To better control costs and schedules" – (please, don’t laugh).

Reliability relies on system specifications and on the operational context.
Safety relies on reliability and on the environmental context.

I won’t insist, but on the current reliability and environmental context "rarely safety problem” is not good.

In facts, “experiencing anomaly 5% of the time” is still too big for an ATS operational context.
(If a flight gets a situation you won’t be sure to get an accurate perspective within that 5% - it will require more efforts).

I can do something with that. But not at Transport Canada: “they need something else has happen” and no one would give that.

When problems can be roughly measured, but no resolved; that goes hard on stress.

That is the same about engineering: when problem can be accurately predicted, but no resolved, that will be hard to take a break. (a failure I mean).

They are always safe and reliable engineering solutions – they don’t cost that much.
In 2005, such experiences were already made on CAATS - as an engineering initiative to evaluating the common CAATS/MAATS feasibility risks.

"very poorly written" I think I can make a little effort: (no one there?)

“Engineers should recognize that reducing risk is not an impossible task, even under financial and time constraints.
All it takes in many cases is a different perspective on the design problem.”

"When you run out of questions, you don't run out of answers, you run out of hope"

[cyvr_2010]

I can only speak to my experience with CAATS but I will make these points:

Your ignorance is astounding.

1.) CAATS has significantly reduced my workload in certain areas, although slightly increased them in others.

Good for you. How about those sectors west of you that have had workload and heads down time feeding the system increased substantively?

2.) I would roughly estimate that only 5% of the time have I seen CAATS experiencing an anomoly which affected my job, but rarely safety (I can control with Splats if I need to, or just with strips in fact I control with strips only on a daily basis in some sectors

How many "work arounds" does your specialty use? Do you know how may are being used in other ACCs? It's commonly known Gander/Moncton don't use certain functions in CAATS. I've heard discussions myself along the lines of "How do you guys use <>" "Uh, we don't".

3.)CAATS needs improvements in some areas, but with each build it seems to be working better, and more stable. I'm definately not saying its perfect by any means, but the reduction in workload that CAATS has brought is something I'd never want to give up.

Once again spoken by a novice with very limited time.Your post smacks of contradictions; "I've never seen an airline go too far above and beyond the regs in terms of safety, although it does happen from time to time, it is a rare thing".I would just stop now if I were you.

[invertedattitude]

Well this is obviously a touchier subject for you two than it is for me.

Once again spoken by a novice with very limited time.Your post smacks of contradictions

You've obviously never worked for an airline before.

I'll put it plain and simple, if you're really that worried about CAATS safety, then you should know how to handle yourself and the channels to take if you're so experienced.

There are many ways to have attention brought to the subject.

Or if you're simply too scared for your job to actually do anything about it, then shut-up and carry on. Complaining on here under the veil of a anonymous web forum will not further your cause, since about 99% of the people who read this forum could care less, and frankly most of this forums readership have no idea what "CAATS" actually is.

I have my own concerns with CAATS, and you're right I don't work in other centres so I don't know their specific problems, but the ones we have we do "work around" or they have been fixed, albeit slowly in many cases.

Insulting me as a novice is rather petty, considering my specialty really has no MAJOR issues with CAATS, and I don't work in other centres how could even an experienced controller know what goes on around the country day to day?

Bottom line, if you're really concerned, then do something about it, whining on a web forum (and a pilots web forum at that) will accomplish nothing.

This forum sub-section was created for pilots to ask ATS related questions or vice-versa, not for Engineers to make random posts about the safety of NavCanadas systems.

[cyvr_2010]

Or if you're simply too scared for your job to actually do anything about it, then shut-up and carry on. Complaining on here under the veil of a anonymous web forum will not further your cause, since about 99% of the people who read this forum could care less, and frankly most of this forums readership have no idea what "CAATS" actually is.

Bottom line, if you're really concerned, then do something about it, whining on a web forum (and a pilots web forum at that) will accomplish nothing.

Your response is laughable.Pontificating about the wonders of the system for your little sector of airspace while ignoring how it affects others across the country. Scared for my job? Given the airspace I work I would be concerned if I were a high controller. Back to the contradiction thing you openly say you have concerns for CAATS yet when others who obviously know more than you express their consternation you attempt admonish and belittle.There are those of us who have been involved in HIRAs, evaluations and seen their SMEs outright ignored so do not give me any of your bullshit about "do something about it". The reason I am posting here is because an uninformed individual such as yourself has put forward a point of view that is blatentley flawed by your inexperience and simple lack of knowing any better.

This forum sub-section was created for pilots to ask ATS related questions or vice-versa, not for Engineers to make random posts about the safety of NavCanadas systems.

So, why do you get to share your views on the system and those who differ do not?

Insulting me as a novice is rather petty, considering my specialty really has no MAJOR issues with CAATS, and I don't work in other centres how could even an experienced controller know what goes on around the country day to day?

Some folk in some ACCs know what goes on outside of their little safety comfy "bubble"

[Michael YVR]

Air Traffic Control provided accurate feedbacks which have brought my analysis on a different perspective, where CAATS safety is not going that bad.

To validate this perspective, I need to know if CAATS problems have surged after Moncton and Gander get implemented (winter 2006), reached a summit with the Montreal ACC’s CAATS breakdown, and then decreased on a slow linear slope down to a threshold matching roughly the winter 2006 previous problem level.
Being a little better or worst than right after the winter 2006 situation is not such significant about CAATS.
About the slope, being decreasing matter, then drowing slow, and quite linearily.

If YES or almost, then the problems come likely from an erroneous modification of the CAATS invariant system parameters, and have faded after those invariants got restored to their functional initial value.

On that perspective, the CAATS critical-safety problems would have been transitory.
Just would remain the initial CAATS/MAATS common deficiencies and a few NavCanada add-ons problems.

Those problems would be still a point to promptly improve; still not to be an easy task, and still shall require a CAATS safety assessment

In facts, modifying even lightly a CAATS invariant is a serial CAATS killer.


Assuming invariants get changed all what follows is my hypothesis:

Unforeseen CAATS deficiencies get triggered: that is still a good point since such deficiencies get caught and put to the engineers’ attention to get resolved – not sure it has exactly happen that way, but they were opportunities.

CAATS behaviours became in conflict. As a result some process variables get erroneous evaluated and such errors were propagated – flying across the CAATS system.

Restoring the CAATS invariants would have immediately restored the CAATS reliability as it was before. But until it happens, a lot of corrective actions must have being required to attempting to fix the problems – (NavCanada engineering should had worked hard, but without a clue). Therefore the return to the “normal” was “progressive”.

All the above assumption are still an hypothesis which need to be confirmed, first from the controller observation of the engineering “progress” and then by a review of the CAATS development process since winter 2006 (all the issues and MR which were implemented, more precisely since IS-CAATS-005770 - this issue was intended to modify a CAATS invariant in order to resolve a flight hand-off problem at the Moncton departure. Indeed the low level jurisdiction was by-passed and modifying a CAATS invariant came in first within the problem description – The problem analysis immediately proscribed such early proposed solution, pointed out a configuration data problem, and put a strong safety risks warning about going forward with a CAATS invariant adjustment).

Here is the contradiction – the problem, which currently meets the facts as reported by Air Traffic Controller, drops a serious doubt about the current CAATS safety, but would be the most stupid improvisation NavCanada would have ever made since NavCanada exist.

As a matter a facts, configuration data set-up was one of the most significant difficulties during the Winnipeg ACC CAATS integration. Safety concerns a consequence of the Montreal ACC breakdown during the CAATS integration.

At this stage there is still no evidence that NavCanada even realised how all the problems get caused, but how brilliant it was when fixing the errors it made itself.

In summary - an amazing maze:
Much ado about nothing about NavCanada engineering.
Almost two years of delay, reliability chaos and safety uncertainty about CAATS.
Stress and comprehensive efforts about all the air traffic controllers.


If the air traffic controllers agree: CAATS is no longer such a safety issue.
If the CAATS engineering process doesn't improve: the CAATS initial reliability problems are for quite a long.
An independent CAATS system safety assessment is necessary and mandatory.

[invertedattitude]

Just one more thing I want to add:

I have friends who work in various CAATS centres other than mine, and it has been interesting to hear their stories through implementation.

It seems to the same story, before and during implementation CAATS to them and their co-workers is the scariest, worst system in the world... then a few months later, the fears seem to subside.

So either:

A) there really are no problems with CAATS, at least at the end user level

B) There really are a ton of problems with CAATS, but we all work around them and only the DSC's and Engineers are aware of the gravity of the situation.

B is quite possible obviously, and from this thread, seems to be the case.

[Michael YVR]

Not a ton of problems, but the room for manoeuvre is narrowing; it is called the "entropy".
Entropy is a term from physics that refers to the amount of "disorder" in a system.
(A big word at NavCanada, great concerns every where else in the ATS world – e.g.: Eurocontrol).

As a result, some CAATS functionality were skipped to saving room, a few others were duplicated just in case a failure happens, so the freed room was reused.
The way it goes doesn’t indicate flexibility: i.e.: that goes to a permanent state, not to a transitory with a progressive return of the lost functionalities.
The paradox CAATS can't afford for long:

• A computer program that is used will be modified.
• When a program is modified, its complexity increase.

Complexity also comes from the CAATS build scattered across 7 different operational perspectives. And CAATS complexity is to differ in amplitude from one ACC to another.
One build-one ACC would have been a better option to reduce the saturation risk and increase the stability, but that was not a feasible option in terms of configuration capability.
Although that already happen: CAATS/MAATS was on the same build, but NavCanada split design and specifications.
And that could have to happen again (i.e.: splitting design and specifications).

The next challenge is the last CAATS commissioning (Edmonton): How all will work with the last piece of the puzzle included?
i.e.: About the CAATS internal behaviour rules, what shall be the impact of switching from the transitional mode (on effect until all ACC commissioning is completed), to the full operational mode?
That something transparent to the controllers, but a CAATS trick to simulate operations (e.g.; hand-off) on behalf of ACC not yet implemented.

On a long sight, from top to the base NavCanada is stuck within structural blockages.
To oppose, the employee culture should try to evolve to a more responsible and communicative approach between departments.
That would reduce risks and give way to improvements.
That should increase the comprehension of risks and reduce the fear to resolving problems.

On a short sight, all concerns put together, right after Edmonton, in the core of the software there is a few perspectives of turbulences into CAATS (functional CAATS reliability needs a reliable confirmation).
Relatively speaking there is no big risk about CAATS safety (need a reliable confirmation), but at the size of Canada, something that can be quite annoying about Vancouver 2010, considering the concurrency of the events - “stretch to the limits to enjoy the benefits” is to be tough as a common expectation.

[felixthecat]

Excuse me for digging up this post

I am from Hong Kong, RTN's Autotrac III is deployed here and target to go operational by mid of this year.

Autotrac III probably is RTN's brand name, Internally, Autotrac III still calls itself "CAATS" everywhere. the name was in fact hard-coded everywhere.

Just wondering, what is the recently status of CAATS with you guys? As there isn't much discussion about these in the past few years.