Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mission Acceptance and Launch Authorization #38

Open
huguesf opened this issue Sep 5, 2019 · 3 comments
Open

Mission Acceptance and Launch Authorization #38

huguesf opened this issue Sep 5, 2019 · 3 comments
Labels
enhancement New feature or request

Comments

@huguesf
Copy link
Collaborator

huguesf commented Sep 5, 2019

AirForce has a requirement that all glider and tow plane launches have Mission Acceptance and Launch Authorization.
Currently done on paper.

As a Pilot and Supervisor
we want to accept and authorize a launch
So that
... meet AirForce requirements (what are those req exactly?).... in case of an incident or accident

Q. What would make acceptance and authorization valid for the app stand point?

Q. What verification would need to be sent to AirForce if requested?

@LukeTowers
Copy link
Contributor

MALA requirements are located here: https://portal-portail.cadets.gc.ca/en/CANCDTGEN/Pages/ord/7002-7-ANN_B.aspx. Some key pieces besides the risk grid itself is what happens with the total score:

NORMAL (15-25): Use standard gliding ops planning and established operating procedures. Send MALA form to RCA Ops O with Time Sheets.
MODERATE (16-35): An elevated risk is present. Inform RCA Ops O or designate prior to initiating flight ops that risk has been assessed as moderate. Consider alternatives to reduce risk. New MALA must be done every 3 hours. MALA must be sent to RCA Ops O immediately upon signature
HIGH (>35): Conditions higher than normal risk. Review all elements to identify those that could be modified to reduce risk including delaying ops until conditions improve. Forward MALA to RCA Ops O immediately. RCA Ops O or delegate must authorize commencement/continuance of operations. MALA must be done every 3 hours after receiving Launch Authorization.

I imagine that before a flight gets launched we could require that the MALA gets filled out and if it meets MODERATE or HIGH then it could trigger a popup (or some other obvious indicator) every three hours (or slightly before) to review and sign off on the MALA (allowing for changes if any have happened)

Q. What verification would need to be sent to AirForce if requested?

We could probably have the app either just require the name and license number for a "signature" (like is currently done when modifying flights of past days) or also add in a "signature" field for users to draw their signature with their finger.

As for what method makes the most sense for actually transmitting the information I think probably the easiest to implement right now (before we have a web application like interface) would be an automated email / text to the designated contact address for the RCA Ops O with a confirmation step on the iPad (by the signing officer) that the MALA was authorized if it required it.

@kirvanp
Copy link
Collaborator

kirvanp commented Sep 8, 2019

Just an idea, but I wonder if there would be some merit in creating a separate MALA app or website? There isn't much information that the MALA requires from the timesheets app database, so there isn't a huge synergy there. The timesheets app itself is already pretty big and complicated and risks getting cluttered.

The MALA app could create its own three hour notifications and have its own syncing features. One could later add modules to it for handling other checklist type tasks such as aircraft daily inspections.

@LukeTowers
Copy link
Contributor

@kirvanp that could work, my main concern would be in making it easy for the CFS staff to do though. If it's in a separate app it's easier to overlook / more of a pain to do on a regular basis.

It could be easily added to the PTR application though (could be a good fit since tracking qualifications like being a DFAO would be the responsibility of the PTR application anyways)

@huguesf huguesf added the enhancement New feature or request label Nov 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants
@huguesf @LukeTowers @kirvanp and others