engine x acting engine y
- Thread starter Petey
- Start date
Y
YFDFireBuff.
Guest
Petey said:
203 Is Probably At A Job Or Something And Not In Service So Engine 201 Is Acting (Taking Over) 203 and responding in there first due ....Hope I said that right. :-\
- Joined
- Apr 2, 2008
- Messages
- 73
When a unit is "acting" another the company, acting is relocated to the 1st due response area of that company, IE: the firehouse....so Eng203 acting Eng201 means 203 is in 201's response area and responsible for all alarms received in that area 1st 2nd or 3rd due and of course EMS.
A relocated company takes on the identity of the unit it is relocated into. Example: Engine 10 Acting Engine 54. We move companies to other firehouses to maintain an adequate amount of fire coverage.
Engine 10's first due response area is left empty, but covered by the companies surrounding them. We can do what is called backfilling. So we may move Engine 10 to Engine 54, and then take Engine 279 and move them to Engine 10, depending on how badly we need coverage. Hope that helps.
Engine 10's first due response area is left empty, but covered by the companies surrounding them. We can do what is called backfilling. So we may move Engine 10 to Engine 54, and then take Engine 279 and move them to Engine 10, depending on how badly we need coverage. Hope that helps.
This has always been one of the things that really fascinates me about FDNY. When you realize that every square inch of the city is covered by an alarm box and that, at some point way before they had computers to help, someone or some group actually sat down and figured out the concept of relocating companies to maintain coverage all over the city is amazing. I wonder if anyone out there knows the history of this part of the FD.
Funny you should mention that. If you ever venture into any of the Dispatchers offices, we have old assignment cards in a large box near the status board(a board we use to track the units when the computer craps out). On each card, it gives a list of pre-determined relocations on each alarm. However, today we pretty much wing it, using our heads and knowledge of the borough to properly make our moves. Anything out of borough has to be requested.
Back in the days of the bells, when say, a third alarm was transmitted for a box in Midtown, more than likely, an Engine from Harlem was looking up the box to see if they either responded, or relocated, and out the door they went.
Back in the days of the bells, when say, a third alarm was transmitted for a box in Midtown, more than likely, an Engine from Harlem was looking up the box to see if they either responded, or relocated, and out the door they went.
- Joined
- Nov 23, 2008
- Messages
- 21
During The War Years, specifically around 1970, the City and the Rand Corporation, a major defense contractor, formed a joint venture called The New York City Rand Corporation for the purpose of bringing technology and private sector management to NY city government. One of the outcomes of that was a computer aided dispatch system (the first one in NYC?) which included an automated relocation module.
The relocation module was touted as a great feature because in the hectic life of the dispatcher at the time (War Years) making relocations to cover unprotected areas of the city was the last thing dispatchers had time to do. So the relocation module was supposed to eliminate those very long periods of time when relocation coverage decisions were not being made and large areas were "un-covered."
The database included the land area where each company was first due, the distance between fire houses, and the frequency of alarms for each company. Then the computer made a quick series of calculations to find which combination of stations should be filled to minimize the average travel distance to an alarm taking into account the probability that any given district would receive an alarm.
It made perfect mathematical sense ... and probably was rarely used in practice. I know about it because I was an engineering student at the time and, amazingly, upon a written request, the Rand Corp mailed me a complete copy of the computer code for the system. Keep in mind this was when you loaded a program into a computer by typing instructions onto thousands of IBM punch cards. Which I did.
Bill E.
The relocation module was touted as a great feature because in the hectic life of the dispatcher at the time (War Years) making relocations to cover unprotected areas of the city was the last thing dispatchers had time to do. So the relocation module was supposed to eliminate those very long periods of time when relocation coverage decisions were not being made and large areas were "un-covered."
The database included the land area where each company was first due, the distance between fire houses, and the frequency of alarms for each company. Then the computer made a quick series of calculations to find which combination of stations should be filled to minimize the average travel distance to an alarm taking into account the probability that any given district would receive an alarm.
It made perfect mathematical sense ... and probably was rarely used in practice. I know about it because I was an engineering student at the time and, amazingly, upon a written request, the Rand Corp mailed me a complete copy of the computer code for the system. Keep in mind this was when you loaded a program into a computer by typing instructions onto thousands of IBM punch cards. Which I did.
Bill E.
The result of the Rand thinktank was Starfire. I'm told it was the envy of all FDs at the time. Here we are, some 35 years later still using the basic code. It's been through some rewrites, patches, additions and it's been ported to run on a VAX versus the original DEC PDP11/75. Even with all of that, it will run circles around any CADS today. The Dept. has tried twice to replace it with "off the shelf" CADS programs from major vendors that have been successful at other, smaller departments and met with failure both times.
- Joined
- Nov 23, 2008
- Messages
- 21
Frank, would you say the relocation module was or was not often used by the dispatchers back in the day? I always wondered about the real world use of that aspect of StarFire.
Bill E.
Bill E.
- Joined
- Jul 19, 2007
- Messages
- 268
Apologies to Frank for jumping in on the question directed to him, but for me this back in the day question is a matter of "been there, done that".
The so-called "dispatch module" in the software was transparent to the dispatchers. The whole program, even if divided into modules by the software, was seamless to us. When an incident occurred, units proposed to respond would pop up on the "decision dispatcher's" screen for editing or approval, as would proposed relocations in the case of an all-hands or greater alarm.
The dispatch force was divided into 5 working "groups". Each group had its own style of running the borough. Some groups were widely known (and criticized) for accepting any and all suggestions from the computer, while other groups routinely edited the relocation suggestions based upon experience and even "hunches" about what would happen next.
So, yes, computer generated relocations were used... big time.
The so-called "dispatch module" in the software was transparent to the dispatchers. The whole program, even if divided into modules by the software, was seamless to us. When an incident occurred, units proposed to respond would pop up on the "decision dispatcher's" screen for editing or approval, as would proposed relocations in the case of an all-hands or greater alarm.
The dispatch force was divided into 5 working "groups". Each group had its own style of running the borough. Some groups were widely known (and criticized) for accepting any and all suggestions from the computer, while other groups routinely edited the relocation suggestions based upon experience and even "hunches" about what would happen next.
So, yes, computer generated relocations were used... big time.
The CADS relocations are rarely used now. The CADS' selection process involves going through the alarm assignment and choosing the nearest unit that will not cause another open area. Usually that means using a unit that would be assigned on the next alarm level.
What the relocation program does do well is tell you which houses to fill so as to close all of the open areas with the least amount of moves.
What the relocation program does do well is tell you which houses to fill so as to close all of the open areas with the least amount of moves.
And, that is where knowing your borough comes in handy. Knowing who can get to a place in the least amount of time without causing a problem somewhere else. And like Frank said, the common denominators, as I call them, make our job a little easier when plugging the holes.
FD347 said:
Frank is completely right here. There are two phases to the relocation process: (A) what house/s should be covered, and (B) what unit/s will we use to cover them or "relocate". The CAD relocation program is a quick way to identify which units you MAY want to cover, but as for the choice of what company is to be used to relocate, the choices almost always SUCKED.
It will probably be impossible to design a system that calculates part (B) considering all the variables a dispatcher must take into account at the time
FDNY operated on an RN (Response Neighborhood) idea. If two similar units (Engines or Trucks) are assigned first and second due to a fixed number of boxes, and are both "seriously unavailable", that is expected to be unavailable for a set time period, a suggestion would be made to fill one of the units.
A better system was proposed some decades back: If ANY single unit was "seriously unavailable" and the adjoining second due unit was greater than x minutes from the uncovered district, a relocation was suggested. A prime example might be if Engine 70 on outlying City Island would be OOS, a relocation to E70 would be suggested. Of course that is what the dispatcher does now, but could also apply to other companies in outlying areas or those with very large response areas such as in eastern Queens or Staten Island. If a unit and its RN partner were relatively close, a relocation may not be needed or suggested.
Back to the static pre-planned relocations printed on the back up assignment cards. These, like many FDNY concepts, operated on the assumption that there was only one fire going on at the time. A usually always incorrect or dangerous assumption. And that is why pre-planned relocations were not worth the paper they were printed on.