PX4 Maintainers Call: August 22, 2023

đź“ž Coordination Calls PX4 Autopilot Coordination
1

:calendar: August 22, 2023

The maintainers meeting is a meeting for the developer team to coordinate on pressing issues and to plan the development of the PX4 Autopilot project, the community is welcome to join and listen, but won’t be able to speak unless specific access is granted ahead of time.

:selfie: Meeting Link

:notebook_with_decorative_cover: Agenda

  • Finalize maintainer role description
  • Identify maintainer opportunities
  • Open mic for maintainers

:memo: Meeting Notes

Remote ID Discussion

Today we had a special guest at our meeting, Gabriel Cox the Chairman of ASTM Remote ID Workgroup, who helped clarify the following points:

Two main topics of discussion:

  1. Emergency Button
  2. Tamper Proof

Emergency Button: The regulation only asks for us to declare the emergency but doesn’t indicate the behavior of the flight stack

7.7.1 For standard RID, the emergency status indicator shall be satisfied using either (or both) of the following methods:

7.7.1.1 The system shall provide a mechanism for the operator to manually assert the emergency status and document this function in the user instructions. If a manual assert mechanism is used, it shall be available to use at the operator’s discretion. > 7.7.1.2 The system shall automatically assert the emergency status at least under the two following conditions: (1) UAS unable to recover from an uncontrolled descent. (2) UAS unable to recover from loss of control of the flight trajectory.

Tamper Proof:

7.5.2 The Remote ID system shall protect Part 89 required broadcasted message elements from being altered through the end-user interface(s) of the system by masking the items from user input. The following message elements are an exception to this requirement:
7.5.2.1 Emergency Status Indicator.
7.5.2.2 ID mode selection of Serial Number or Session ID

Additionally

To be accepted by the FAA, an MOC must meet the requirements of both subparts D and E of part 89. An MOC must address the minimum performance requirements, as well as the testing and validation necessary to demonstrate compliance with the part 89 subpart D requirements.

Lastly

  1. The remote identification system shall protect the part 89-required broadcasted message from being altered or disabled by any person.

  2. The remote identification system shall incorporate techniques or methods that reduce the ability of any person to physically and functionally modify or disable any aspect or component of the remote identification system that could impact compliance with the remote identification rule.

  3. In applying Section 7.5.2 of ASTM F3586-22, the applicant shall determine whether masking the specified items from user input adequately provides the functional tamper resistance protection specified by this means of compliance, and if it does not, shall incorporate additional functional tamper resistance techniques or methods in accordance with this means of compliance.

https://www.federalregister.gov/documents/2022/08/11/2022-16997/accepted-means-of-compliance-remote-identification-of-unmanned-aircraft#:~:text=To%20be%20accepted%20by%20the,part%2089%20subpart%20D%20requirements

Gabriel: It’s important to clarify we don’t need to be tamper-proof, only tamper resistance and evidence we are reducing the ability of a user to modify their location

v1.14 Release

Flight Logs and Issues
Regression from one of the changes about a month ago or so. We have a pr already to fix it. We need help testing this PR from Fixed Wings. Let’s give it another flight. It’s been SITL tested already.

Remote ID Feature
We are targeting to add Remote ID to the release. We are in the final phases of the implementation. The feature might not make it to v1.14.0 and might require a v1.14.1 point release shortly afterward.

Timeline
We are targeting a release in the next week (cc @hamishwillee), we will do a final pass on the release notes and announcement.

Debugging Hardware

Debugging Microcontrollers

2

Can I please have a discussion of {Sponsored by Intelliterra} Added MAV_CMD_DO_SET_EMERGENCY for manual emergency setting by jnomikos · Pull Request #2027 · mavlink/mavlink · GitHub. This adds a MAVLink command MAV_CMD_ODID_SET_EMERGENCY. You’d have an emergency button in the GCS, which the pilot could press to send this to PX4, which would then populate the LOCATION message for Remote ID with the emergency status.

This is a requirement of the spec, but I think it makes little sense. If there is an emergency then I should be doing something to avert the problem - my first action isn’t to tell Remote ID about it.

We probably need more information about how this could/should/would be implemented.

This might be better to discuss in Remote ID WG - but posted it here for visibility.

1 Like
3

I’d be happy to discuss this with anyone if you need further clarification. The requirements are in the MOC, it’s an alternative to the automated emergency assertion algorithm spelled out in the MOC. The notion of “flying the aircraft” as 1st priority prior to communicating an emergency is not new – it is part of the creed of manned aviation (Aviate, Navigate, Communicate – in that order). However flying the aircraft and communicating an emergency (as a secondary priority) is not a task that is mutually exclusive.

Gabriel Cox
Chairman, ASTM Remote ID Workgroup

1 Like
4

Thanks @gabrielcox

@rroche Yes, but right now is PX4 tamper resistant with respect to this ID, and if not, what are we doing to mitigate?

5

According to @gabrielcox we only need to remove the ability for a user to change the ID and location via the UI in QGC. Nothing more.

6

@gabrielcox FAA told ArduPilot they needed to have non-modifiable parameters in signed firmware to meet this requirement. My concern is that if PX4 are getting different direction, we might later discover that we need to do more when it is too late for existing vehicles.

FWIW I don’t see hiding this in QGC as any kind of protection - you don’t have to use QGC as the GCS, you could use an older version, or MAVSDK, and so on.

@rroche No more crying wolf from me on this topic (though I reserve the right to later on deliver an “I told you so”).

7

@rroche , There’s 3 layers of requirements to meet re: Tamper Resistance. I pasted the text from the MOC and NOA in the chat, so it’s probably best to focus on the textual requirements.

Here’s the 3 layers:

  1. What does the rule say?:
    Part 89.310(d): Tamper resistance. The unmanned aircraft must be designed and produced in a way that reduces the ability of a person to tamper with the remote identification functionality.

  2. What does the accepted means of compliance (ASTM MOC) say?:

7.5.2 The Remote ID system shall protect Part 89 required
broadcasted message elements from being altered through the
end-user interface(s) of the system by masking the items from
user input. The following message elements are an exception to
this requirement:
7.5.2.1 Emergency Status Indicator.
7.5.2.2 ID mode selection of Serial Number or Session ID.
NOTE 7—End-user interfaces include the following: External Buttons,
screens, add-on devices (such as cell phones/apps), external wiring
interfaces + supporting software.
7.5.3 For Standard RID, as required in 7.2.2, the RID
system must perform a PFST. If the aircraft RID location
source hardware and software or RID transmit hardware and
software are detected not functional as described in 7.2.3, due
to tampering or other failure, then taking flight shall be
prevented by the control system. This take-off prevention
feature shall be protected from being altered through the
end-user interface(s) of the system.

  1. What does the FAA Notice of Acceptance (NOA) say?:
    Although the FAA accepted the MOC, they did add “Additions” in terms of additional requirements:

  1. The remote identification system shall protect the part 89-required broadcasted message from being altered or disabled by any person.

  2. The remote identification system shall incorporate techniques or methods that reduce the ability of any person to physically and functionally modify or disable any aspect or component of the remote identification system that could impact compliance with the remote identification rule.

  3. In applying Section 7.5.2 of ASTM F3586-22, the applicant shall determine whether masking the specified items from user input adequately provides the functional tamper resistance protection specified by this means of compliance, and if it does not, shall incorporate additional functional tamper resistance techniques or methods in accordance with this means of compliance.

One more thing PX4 needs to consider is what is in the scope of PX4 development and what is in the scope of the final system integrator. What is regulated is the UAS (not the software or hardware components). However, the final system integrator/producer must be able to use the software and hardware components available and construct a compliant solution.

@hamishwillee To meet “FAA Addition #1”, you could certainly argue signed firmware technologies could be used to meet the requirement. There may be other ways to meet it as well. The FAA was quite non-prescriptive here. If you heard an individual opinion from an FAA employee, I would certainly try to gather clarity as to whether it’s an official position, or an individual’s opinion. I’ve only seen them provide official positions in writing, but more than willing to discuss the merits (and give unofficial opinions) in a debate on using one technique vs another.

As far as the NOA language goes, I did submit comments (and other orgs endorsed them in the other comments) to attempt to get them to narrow the ambiguity:
https://www.federalregister.gov/documents/2022/08/11/2022-16997/accepted-means-of-compliance-remote-identification-of-unmanned-aircraft
They have unfortunately not adopted these suggested changes.

1 Like
8

Thank you. I guess we’ll play wait and see.