lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

I used Lua for the embedded controller in a laboratory instrument that eventually would have become a clinical medical device down the road. Priorities changed, but the prototype worked great in the lab.

The modifications you are describing are about tailoring Lua for a specific target environment. That is fine, but they are not about safety. Making a safe device requires having a good overall device design and architecture, and following a good process. For medical device software, IEC 62304 is a good standard. I'm not familiar with automotive. But safety is basically good common sense.

- Determine the overall safety level of concern. In other words, what is the worst that could happen, that the device is responsible for.
- Write a draft functional specification at the beginning of the project and update it as you refine the design.
- Do a risk analysis and identify the risks that need to be mitigated in the design.
- Ensure that all the behavior of the device is by design. Do not take advantage of undocumented features or emergent behavior that could change unexpectedly.
- Have a design that enables the Lua scripts to be unit tested. It's also good to have a simulation environment, so scripts can be developed without the risk of breaking things or hurting people.
- Have a test plan for validating the device components, including Lua, and for validating the integrated device.

Lua itself is not a serious risk. It is a language and runtime. People use Java, C#, Python, Javascript, etc., for safety-critical systems.

Validating Lua requires demonstrating that it is fit for its intended use. This is not a big deal. For example, the intended use is a scripting engine that allows logic to be defined in scripts that can be updated without rebuilding the software. The scripting engine has to be able to call functions implemented in C/C++, call functions at X or more functions/second, fit within X MB of space, be widely used, and open source so it can be modified if need be. Lua is obviously a great fit for that intended use. Demonstrating it should take only a day or two.

When the integrated device is validated, Lua will be a part of it. So Lua will be tested as used in the device. The important thing is that the validation should cover all the kinds of scripts that might actually be used in the field.


-----Original Message-----
From: Roger Leigh <>
Sent: Sunday, February 5, 2023 12:07 PM
Subject: Lua usage in safety-critical systems

EXTERNAL EMAIL - Use caution opening attachments and links.

Hi folks,

I'm new to the mailing list, and would be interested to know if anyone has used Lua in any sort of safety-critical system, in particular for regulated industries such as automotive or medical.  If anyone has any examples of such use in a real product that would be really interesting and much appreciated.

For a bit of context, I'm currently investigating use of Lua in an embedded device running as a dedicated RTOS thread for high-level scripting of actions.  I have developed an initial proof of concept with several safety mitigations including a custom pool allocator and made some other small modifications to make Lua work in this constrained environment. From a purely technical perspective, everything is working very well.  However, without being aware of any precedence for Lua being used for this type of application, it is a potential regulatory risk, and so any pre-existing use of Lua for this type of situation would make it a less risky proposition.

If making the stock Lua source code work on embedded systems is of wider interest, I can potentially feed back some of the changes I've made which include:

  - disabling of all file I/O for systems without any file system or FILE streams [mainly a handful of ifdefs]
  - replacement of the random functions using clock() and time() with a hardware RNG [would weak symbols with a LUA_WEAK macro be acceptable, or should this go into Lua_State as a function pointer like for the memory allocator?]
  - replacement of some of the output/logging functions to use alternative means of logging in the absence of FILE streams (same question as for the random functions regarding weak symbols or function pointer)

Many thanks,
This message may constitute an advertisement of a BD group's products or services or a solicitation of interest in them. If this is such a message and you would like to opt out of receiving future advertisements or solicitations from this BD group, please forward this e-mail to [BD.v1.0]
This message (which includes any attachments) is intended only for the designated recipient(s). It may contain confidential or proprietary information and may be subject to the attorney-client privilege or other confidentiality protections. If you are not a designated recipient, you may not review, use, copy or distribute this message. If you received this in error, please notify the sender by reply e-mail and delete this message. Thank you.
Corporate Headquarters Mailing Address: BD (Becton, Dickinson and Company) 1 Becton Drive Franklin Lakes, NJ 07417 U.S.A.