How do we pass from Take-Off to Climb in F_MM

[AnthonyLeonardoGracio]

In 6.6.4 Figure 3, we can see that we pass from the Take-Off state to the Climb state after some time.

How do we know how much time we have to wait? Is it ok consider we are in the Climb state when the Current_Altitude is different from 0?

[ledinot]

Anthony, in your text. E.

De : Anthony Leonardo Gracio [mailto:notifications@github.com] Envoyé : jeudi 6 juillet 2017 14:53 À : AdaCore/RESSAC_Use_Case Cc : Subscribed Objet : [AdaCore/RESSAC_Use_Case] How do we pass from Take-Off to Climb in F_MM (#28)

In 6.6.4 Figure 3, we can see that we pass from the Take-Off state to the Climb state after some time.

How do we know how much time we have to wait?

Take-off is a short phase with low acceleration rates (horizontal and vertical) to take care of the field operator (in case we would have stayed close to the drone after pressing the start button).

Duration of this phase, like that for any other phase, is not a matter of predefined number of seconds.

It is a matter of reaching the Take-Off preset operating point (Altitude_ref_TakeOff or Speed_ref_TakeOff), defining the end of the phase.

Duration is defined by events on the continuous dynamics (zero-crossings), not by down-counting a clock (timeouts).

Is it ok consider we are in the Climb state when the Current_Altitude is different from 0?

You can do that (it is consistent with my previous answer), but it reduces TakeOff to a null phase.

I would prefer you see TakeOff as a first climb phase that has particular safety constraints (that is the case in the certification specification, you may have a look at the document in the Safety Process folder).

The target Speed or Altitude that define end of TakeOff are common to any mission (not dependent of NAV parameters, ‘hardwired’ in memory).

This way, there is some duration of TakeOff, and specific safety objectives can be verified on this phase.

It was not made precise in the specification, I agree (so it has to be added ☺).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/AdaCore/RESSAC_Use_Case/issues/28, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVVweP1XIUz7dDH1YV9BD9r6XUI6xEmpks5sLNi_gaJpZM4OPl7Q.

[clairedross]

Hi Emmanuel,

Thanks for your answers. I have an additional question regarding your explanations:

It is a matter of reaching the Take-Off preset operating point (Altitude_ref_TakeOff or Speed_ref_TakeOff), defining the end of the phase.

You gave both an altitude and a speed. How do we choose between the two? Does it depend on the navigation option (SPEED, ALTITUDE, ENERGY) ? If yes, how does F_MM know how to choose as it is F_FC which chooses between ALTITUDE and SPEED in ENERGY mode? Or is it F_FC which tells F_MM that take_off is over ? Indeed, Altitude_ref_TakeOff and Speed_ref_TakeOff look more like something that F_FC would need rather than F_MM, but I suppose F_MM can give them to F_FC through Operating_Point during take_off?

Thanks for you help,

-- Claire Dross, PhD Software Engineer dross@adacore.com

[ledinot]

Hi Claire,

You are right, regrading end of the Take-Off phase in Energy mode, there is a little mess (presently implicit, or even unspecified).

The rational of this first cheap implementation of the Energy mode is “autoamtic choice of Altitude mode or Speed mode: the system-chosen mode is the least energy demanding one, given the two user-defined values for cruise Altitude and Speed”.

For Take-Off, the situation is slightly different because the user (field operator or GS operator) has no influence on the target Speed, nor on the target Altitude, that condition end of the Take-Off phase. The two values are hard-wired once for all (in F_MM rather than F_FC, but in both of them would not be shocking).

We can still apply the same policy and be uniform over the phases. The viability tables can give which of the two hardwired take-off is the more energy efficient. We can even store this information once for all, after initial load of the viability tables or after first boot of the systems. Note: an update protocol of these tables is not part of the use case. It could be added if reinforcement of the use case on Parameter Data Items aspects turns out to be needed.

So Take-Off in Energy mode = Take-Off in Altitude mode once for all (or in Speed mode once for all if …).

At least F_MM has to “manage” this hard-wired choice. If the interface F_MM -> F_FC is not able to support Take-Off in a uniform way wt. the other phases, one could also “hard-wire” in F_FC. F_FC would know once for all that for Take-Off, Energy mode means Altitude mode (or Speed mode if …).

To be added in the L1 MMS Functional spec. document.

Hope this helps, Emmanuel

De : Claire Dross [mailto:notifications@github.com] Envoyé : mardi 11 juillet 2017 15:07 À : AdaCore/RESSAC_Use_Case Cc : Ledinot Emmanuel; Assign Objet : Re: [AdaCore/RESSAC_Use_Case] How do we pass from Take-Off to Climb in F_MM (#28)

Hi Emmanuel,

Thanks for your answers. I have an additional question regarding your explanations:

It is a matter of reaching the Take-Off preset operating point (Altitude_ref_TakeOff or Speed_ref_TakeOff), defining the end of the phase.

You gave both an altitude and a speed. How do we choose between the two? Does it depend on the navigation option (SPEED, ALTITUDE, ENERGY) ? If yes, how does F_MM know how to choose as it is F_FC which chooses between ALTITUDE and SPEED in ENERGY mode? Or is it F_FC which tells F_MM that take_off is over ? Indeed, Altitude_ref_TakeOff and Speed_ref_TakeOff look more like something that F_FC would need rather than F_MM, but I suppose F_MM can give them to F_FC through Operating_Point during take_off?

Thanks for you help,

-- Claire Dross, PhD Software Engineer dross@adacore.com<mailto:dross@adacore.com>

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/AdaCore/RESSAC_Use_Case/issues/28#issuecomment-314437218, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVVweL7JqtHOZFhLyA8T8icRdPyxmGUkks5sM3NsgaJpZM4OPl7Q.

[clairedross]

Hi Emmanuel,

Thanks for your answers. Still a couple of small points below, to be sure I understand:

Le 12/07/2017 à 11:38, Emmanuel Ledinot a écrit :

For Take-Off, the situation is slightly different because the user (field operator or GS operator) has no influence on the target Speed, nor on the target Altitude, that condition end of the Take-Off phase. The two values are hard-wired once for all (in F_MM rather than F_FC, but in both of them would not be shocking).

OK, so F_MM will give then to F_FC through the OperatingPoint output, is that it?

The viability tables can give which of the two hardwired take-off is the more energy efficient. We can even store this information once for all, after initial load of the viability tables or after first boot of the systems.

OK, so I can add a new data item EnergyModeForTake-Off or something like that?

At least F_MM has to “manage” this hard-wired choice. If the interface F_MM -> F_FC is not able to support Take-Off in a uniform way wt. the other phases, one could also “hard-wire” in F_FC.

I suppose this is a choice for you to make. Should we add a new signal TakeOffOver from F_MM to F_FC?

Thanks again,

-- Claire Dross, PhD Software Engineer dross@adacore.com

[ledinot]

De : Claire Dross [mailto:notifications@github.com] Envoyé : mercredi 12 juillet 2017 11:48 À : AdaCore/RESSAC_Use_Case Cc : Ledinot Emmanuel; Assign Objet : [Message publicitaire : ] Re: [AdaCore/RESSAC_Use_Case] How do we pass from Take-Off to Climb in F_MM (#28)

Hi Emmanuel,

Thanks for your answers. Still a couple of small points below, to be sure I understand:

Le 12/07/2017 à 11:38, Emmanuel Ledinot a écrit :

For Take-Off, the situation is slightly different because the user (field operator or GS operator) has no influence on the target Speed, nor on the target Altitude, that condition end of the Take-Off phase. The two values are hard-wired once for all (in F_MM rather than F_FC, but in both of them would not be shocking).

OK, so F_MM will give then to F_FC through the OperatingPoint output, is that it?

Yes it is.

The viability tables can give which of the two hardwired take-off is the more energy efficient. We can even store this information once for all, after initial load of the viability tables or after first boot of the systems.

OK, so I can add a new data item EnergyModeForTake-Off or something like that?

Yes.

At least F_MM has to “manage” this hard-wired choice. If the interface F_MM -> F_FC is not able to support Take-Off in a uniform way wt. the other phases, one could also “hard-wire” in F_FC.

I suppose this is a choice for you to make. Should we add a new signal TakeOffOver from F_MM to F_FC?

No, it is not a choice I have to make. I consider the expected behavior at system level is now thoroughly defined (up to the next issue :-)) and assignment of roles to the functions to be defined as well. To me the system&functional interface between F_FM and F_FC is also sufficiently and consistently defined (the spec increment does not necessitate an interface update). As you mentioned F_MM will give then to F_FC through the OperatingPoint output.

So to me, “Should we add a new signal TakeOffOver from F_MM to F_FC?” is a question for you, not for me. You can add it if you feel your software would benefit from this extra information (for simplicity, maintainability etc.).

Thanks again,

-- Claire Dross, PhD Software Engineer dross@adacore.com<mailto:dross@adacore.com>

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/AdaCore/RESSAC_Use_Case/issues/28#issuecomment-314712610, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVVweK_uwyygQurhy66Lhu7I56bOtNy5ks5sNJZjgaJpZM4OPl7Q.

[clairedross]

Thanks, I think it is clear now. From your last answer, I understand F_FC does not actually need the information that we are in take off phase or not from a system perspective (no particular safety constraints to check). This is OK with me.

-- Claire Dross, PhD Software Engineer dross@adacore.com

[ledinot]

I didn’t say no particular safety constraints …

I even defended the opposite view to Antony! They are specific safety constraints for Take-Off (monitoring side of the control law), but it does not imply you need to add an extra signal to the interface, or that the system needs required to do that (unless you convince me that there is a contradiction or severe deficiency somewhere if the this signal is not added).

De : Claire Dross [mailto:notifications@github.com] Envoyé : mercredi 12 juillet 2017 12:21 À : AdaCore/RESSAC_Use_Case Cc : Ledinot Emmanuel; Assign Objet : [Message publicitaire : ] Re: [AdaCore/RESSAC_Use_Case] How do we pass from Take-Off to Climb in F_MM (#28)

Thanks, I think it is clear now. From your last answer, I understand F_FC does not actually need the information that we are in take off phase or not from a system perspective (no particular safety constraints to check). This is OK with me.

-- Claire Dross, PhD Software Engineer dross@adacore.com<mailto:dross@adacore.com>

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/AdaCore/RESSAC_Use_Case/issues/28#issuecomment-314719963, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVVweDNl_8Z0mIrAlnBrMmiDOhGxNGpCks5sNJ4jgaJpZM4OPl7Q.

[clairedross]

Le 12/07/2017 à 12:27, Emmanuel Ledinot a écrit :

I didn’t say no particular safety constraints …

I even defended the opposite view to Antony! They are specific safety constraints for Take-Off (monitoring side of the control law), but it does not imply you need to add an extra signal to the interface, or that the system needs required to do that (unless you convince me that there is a contradiction or severe deficiency somewhere if the this signal is not added).

Then I am not sure I understand. If F_FC does not have access to the reference values for take-off (speed, altitude and energy mode) and F_MM does not tell it when take-off is over, how can it apply particular safety constraints in Take-Off phase?

-- Claire Dross, PhD Software Engineer dross@adacore.com

[ledinot]

Claire, in your text. E.

De : Claire Dross [mailto:notifications@github.com] Envoyé : mercredi 12 juillet 2017 12:32 À : AdaCore/RESSAC_Use_Case Cc : Ledinot Emmanuel; Assign Objet : [Message publicitaire : ] Re: [AdaCore/RESSAC_Use_Case] How do we pass from Take-Off to Climb in F_MM (#28)

Le 12/07/2017 à 12:27, Emmanuel Ledinot a écrit :

I didn’t say no particular safety constraints …

I even defended the opposite view to Antony! They are specific safety constraints for Take-Off (monitoring side of the control law), but it does not imply you need to add an extra signal to the interface, or that the system needs required to do that (unless you convince me that there is a contradiction or severe deficiency somewhere if the this signal is not added).

Then I am not sure I understand. If F_FC does not have access to the reference values for take-off (speed, altitude and energy mode) and F_MM does not tell it when take-off is over, how can it apply particular safety constraints in Take-Off phase?

Why so ? End of take-off occurs when the first operating point, specifically designed to mark the end of the take-off phase, is reached. F_FC has access to the “End of Take-Off” event, in two ways:

1. the end-of-take-off reference point is sent by F_MM to F_FC (like for all the other phases) and then this point is reached.

The only difference with the other phases is that the value of this first reference point is always the same one.

2. F_MM does not send this constant first operating point because software design (and system specification) tended to view this constant exchange as better addressed by a “parameter” stored in F_FC.

Then F_FC needs from F_MM the mission “start” event, but nothing more.

F_MM needs from F_FC the means to detect the end of the take-off phase, yes, to send at the right time the next reference point (i.e the end-of-climb reference point). Since F_FC gives « continuous » (Distance(t), Altitude(t), Speed(t)) feedback to F_MM, and since F_MM also knows the constant reference point used for take-off, it can perform this detection without any ad-hoc help from F_FC.

Claire Dross, PhD Software Engineer dross@adacore.com<mailto:dross@adacore.com>

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/AdaCore/RESSAC_Use_Case/issues/28#issuecomment-314722250, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVVweCNpNL8TXP4TCt4gYkjFS7TA0_Esks5sNKCvgaJpZM4OPl7Q.

[clairedross]

Le 12/07/2017 à 15:41, Emmanuel Ledinot a écrit :

1. the end-of-take-off reference point is sent by F_MM to F_FC (like for all the other phases) and then this point is reached.

The only difference with the other phases is that the value of this first reference point is always the same one.

I think this first way is the one we were discussing. So F_FC knows that Take_Off is over when we are in take_off phase and a set point is reached. OK, perfect. Thanks.

-- Claire Dross, PhD Software Engineer dross@adacore.com

[clairedross]

Just one last stupid question. Here is a (maybe a bit far fetched) scenario:

• We start Take-Off in ALTITUDE mode, so F_MM is waiting for current_altitude to reach altitude_ref_takeoff to send the next operating point.

• There is too much wind, F_FC starts braking, so it uses speed_ref_takeoff as a setpoint and reaches it, but notaltitude_ref_takeoff .

Now F_FC thinks Take-Off is over and F_MM does not send a new setpoint.

Is that a problem?

Thanks and sorry for being slow,

-- Claire Dross, PhD Software Engineer dross@adacore.com

[ledinot]

In your text.

De : Claire Dross [mailto:notifications@github.com] Envoyé : mercredi 12 juillet 2017 15:56 À : AdaCore/RESSAC_Use_Case Cc : Ledinot Emmanuel; Assign Objet : [Message publicitaire : ] Re: [AdaCore/RESSAC_Use_Case] How do we pass from Take-Off to Climb in F_MM (#28)

Just one last stupid question. Here is a (maybe a bit far fetched) scenario:

• We start Take-Off in ALTITUDE mode, so F_MM is waiting for current_altitude to reach altitude_ref_takeoff to send the next operating point.

• There is too much wind, F_FC starts braking,

OK on your scenario, up to this point.

so it uses speed_ref_takeoff as a setpoint and reaches it, NO.

If a gust of wind occurs during take-off, the PID controller in Altitude mode will compensate for the disturbance. Disturbances, even when triggering actions on brakes, cannot change the navigation option. In other words, braking may happen without the speed mode being active. Braking is not specific to the speed mode. Braking is activated when needed by the PID controllers (zeroing of the error values) , whatever navigation option is selected.

Beware: there is a difference of time scale

• wind gusts bear on flight control: stability, drone’s attitude = short term horizon (seconds or milliseconds)
• SPEED/ALTITUDE/ENERGY options bear on navigation, drone’s trajectory. Mid-term, long term horizon (minutes or hours).

Think braking mainly as an urgency action, on the short term horizon, independently of the long term horizon. Note: wind has also a long term effect on energy consumption, but that’s not the point here.

I acknowledge that, since the take-off phase is just a few seconds long, this distinction between short term & long term nearly vanishes. The rule to keep in mind is that even though braking has effect primarily on speed, F_FC has control on speed even when the navigation option is not SPEED.

but notaltitude_ref_takeoff .

Now F_FC thinks Take-Off is over and F_MM does not send a new setpoint.

Is that a problem?

Thanks and sorry for being slow,

-- Claire Dross, PhD Software Engineer dross@adacore.com<mailto:dross@adacore.com>

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/AdaCore/RESSAC_Use_Case/issues/28#issuecomment-314776914, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVVweGYLvF66H4ofLXM8NB12-g3-_mH4ks5sNNB2gaJpZM4OPl7Q.

[clairedross]

But the PID for braking always regulates on speed, right?

-- Claire Dross, PhD Software Engineer dross@adacore.com

[clairedross]

Le 13/07/2017 à 13:21, Claire Dross a écrit :

But the PID for braking always regulates on speed, right?

By the way, don't feel oblige to answer, I do not really need to understand how the AV will work for this issue.

-- Claire

[ledinot]

If the PID always regulated on speed, the ALTITUDE mode would have no effect. The PID regulates on speed in SPEED mode, and on altitude in ALTITUDE mode. The building of the error value (the difference between the reference value and the current value) given to the PID controller is precisely the place where the Navigation mode comes into play. Both kinds of reference are used for cruise, climb or descent (and even take-off) regulation.

Sincerely, Emmanuel

De : Claire Dross [mailto:notifications@github.com] Envoyé : jeudi 13 juillet 2017 13:22 À : AdaCore/RESSAC_Use_Case Cc : Ledinot Emmanuel; Assign Objet : [Message publicitaire : ] Re: [AdaCore/RESSAC_Use_Case] How do we pass from Take-Off to Climb in F_MM (#28)

But the PID for braking always regulates on speed, right?

-- Claire Dross, PhD Software Engineer dross@adacore.com<mailto:dross@adacore.com>

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/AdaCore/RESSAC_Use_Case/issues/28#issuecomment-315049742, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVVweFf9GwwhSBjiUyL4Nr5BhkzV_0zgks5sNf2_gaJpZM4OPl7Q.

[clairedross]

Le 13/07/2017 à 14:14, Emmanuel Ledinot a écrit :

If the PID always regulated on speed, the ALTITUDE mode would have no effect. The PID regulates on speed in SPEED mode, and on altitude in ALTITUDE mode. The building of the error value (the difference between the reference value and the current value) given to the PID controller is precisely the place where the Navigation mode comes into play. Both kinds of reference are used for cruise, climb or descent (and even take-off) regulation.

OK, I had the impression that ALTITUDE mode had no effect during braking because of the following lines from 6.7.4:

Braking Control The algorithm is a simpler version of the preceding one: the Speed/Altitude option has no longer influence. error(t) is always computed from the speed.

-- Claire

[ledinot]

Humm… Good point Claire, also related to your new #30. I need some time before giving a definite answer.

Comment (for lessons learnt): the specification was written before modelling and simulation. Modelling is in progress, sometimes I answer under is influence without thoroughly consulting the text (and so I drift a bit) This part of the specification is the most difficult and fragile one, likely to evolve.

Interim answers:

• I was wrong when being non uniform on propulsion and braking (i.e Altitude-based regulation for the short braking phases should be possible). In good conditions (with small wind gusts) propulsion-only control is enough (‘braking’ = less propulsion). The braking micro-phases are short “emergency-like” actions to cope with strong and lasting disturbances. I thought a simplified control (a single kind of reference to be tracked; i.e SPEED) was a good idea because the baking actions are intended to be short. But this so-called simplification is a complication indeed. So forget it. The ALTITUDE/SPEED choice pervades both propulsion and braking PID controllers, for any (macro)-phase i.e take-off (the shortest ‘macro’-phase :-), climb, cruise, descent, and landing.

• PIDs’ coefficients are different when actuation is engine-based or clutch-based. So it is 3 pairs of tables (PhaseX-Populsion-PID table, Phase-X-Braking-PID table), not 3 tables as I wrote it the first time. I will confirm on #30’s thread by end of modelling and simulation.

Best, E.

De : Claire Dross [mailto:notifications@github.com] Envoyé : jeudi 13 juillet 2017 14:24 À : AdaCore/RESSAC_Use_Case Cc : Ledinot Emmanuel; Assign Objet : [Message publicitaire : ] Re: [AdaCore/RESSAC_Use_Case] How do we pass from Take-Off to Climb in F_MM (#28)

Le 13/07/2017 à 14:14, Emmanuel Ledinot a écrit :

If the PID always regulated on speed, the ALTITUDE mode would have no effect. The PID regulates on speed in SPEED mode, and on altitude in ALTITUDE mode. The building of the error value (the difference between the reference value and the current value) given to the PID controller is precisely the place where the Navigation mode comes into play. Both kinds of reference are used for cruise, climb or descent (and even take-off) regulation.

OK, I had the impression that ALTITUDE mode had no effect during braking because of the following lines from 6.7.4:

Braking Control The algorithm is a simpler version of the preceding one: the Speed/Altitude option has no longer influence. error(t) is always computed from the speed.

-- Claire

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/AdaCore/RESSAC_Use_Case/issues/28#issuecomment-315062092, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVVweGdcIc9dUSdKHsO9GuFDvC1gQleeks5sNgx2gaJpZM4OPl7Q.

[clairedross]

OK, thanks for your answers.

-- Claire

[SylvanDissoubray]

Hi,

I have read this very interesting, and very long thread, difficult to understand in one go...

About comments handling:

First, I suggest that identified requirements in the spec, together with proposed clarification of them when needed in discussion threads (prior to approval and insertion in a v2 document) is the most productive way to go. There cannot be better explanation than the requirement itself because the correct requirement expression that is pursued is the one that maximizes clarity, thoroughness and minimizes noise. This is not a constructive property (does not help to create the perfect requirement) but it is a fix-point one (whenever better formulation, replacement of less clear ensures property is preserved). Other way to state this; when requirements need lengthy side explanation, it is very often the sign of needed reformulation.

On the subject of this thread (TakeOff phase):

One strong difficulty for me in understanding the specification is about speed OR altitude formulations (in this thread, in the whole spec text). This is because I try to avoid any intuitive taken for granted understanding.

There are many places in the spec (and in this thread) where behavior is described in terms of SPEED OR ALTITUDE, sometimes SPEED AND ALTITUDE.

At beginning of this thread EL mentions that take off is terminated when Altitude_ref_TakeOff or Speed_ref_TakeOff is reached.

If meaning is when Altitude_ref_TakeOff is reached when in ALTITUDE mode , Then this should be explicit, I do not take it for granted.

At minimum the spec should indicate SPEED or ALTITUDE in any behavior descriptions shall be interpreted as SPEED when in SPEED regulation mode or ALTITUDE when in ALTITUDE regulation mode unless stated otherwise.

[ledinot]

Hi Sylvan,

If meaning is when Altitude_ref_TakeOff is reached when in ALTITUDE mode , Then this should be explicit, I do not take it for granted. I agree there are (many) places in the text where the mode (ALTITUDE resp. SPEED) is implicit, and I only mention the parameter used as reference for regulation. This is because there is a sentence somewhere upstream (I have to find it when closing the issue), which says that in ALTITUDE (resp. SPEED) mode, regulation is exclusively based on ALTITUDE (resp. SPEED). So conversely, if for any specification trait I mention conditions on ALTITUDE (resp. SPEED) as operating point reference parameter, it implies that ALTITUDE mode (resp. SPEED mode) is active.

I will not follow your advice (systematically making the mode explicit everywhere because it would be boring for the reader), but I will underline this equivalence and make an explicit warning on the implicit.

De : SylvanDissoubray [mailto:notifications@github.com] Envoyé : mercredi 30 août 2017 15:34 À : AdaCore/RESSAC_Use_Case Cc : Ledinot Emmanuel; Assign Objet : [Message publicitaire : ] Re: [AdaCore/RESSAC_Use_Case] How do we pass from Take-Off to Climb in F_MM (#28)

Hi,

I have read this very interesting, and very long thread, difficult to understand in one go...

About comments handling:

First, I suggest that identified requirements in the spec, together with proposed clarification of them when needed in discussion threads (prior to approval and insertion in a v2 document) is the most productive way to go. There cannot be better explanation than the requirement itself because the correct requirement expression that is pursued is the one that maximizes clarity, thoroughness and minimizes noise. This is not a constructive property (does not help to create the perfect requirement) but it is a fix-point one (whenever better formulation, replacement of less clear ensures property is preserved). Other way to state this; when requirements need lengthy side explanation, it is very often the sign of needed reformulation.

On the subject of this thread (TakeOff phase):

One strong difficulty for me in understanding the specification is about speed OR altitude formulations (in this thread, in the whole spec text). This is because I try to avoid any intuitive taken for granted understanding.

There are many places in the spec (and in this thread) where behavior is described in terms of SPEED OR ALTITUDE, sometimes SPEED AND ALTITUDE.

At beginning of this thread EL mentions that take off is terminated when Altitude_ref_TakeOff or Speed_ref_TakeOff is reached.

If meaning is when Altitude_ref_TakeOff is reached when in ALTITUDE mode , Then this should be explicit, I do not take it for granted.

At minimum the spec should indicate SPEED or ALTITUDE in any behavior descriptions shall be interpreted as SPEED when in SPEED regulation mode or ALTITUDE when in ALTITUDE regulation mode unless stated otherwise.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/AdaCore/RESSAC_Use_Case/issues/28#issuecomment-325991673, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVVweCsfn-Ezc9N51xVToT8fV38wkp3uks5sdWThgaJpZM4OPl7Q.

[SylvanDissoubray]

Thank you Emmanuel. Fine for me.