What is a requirements system?

1. Think of every feature our solar car or a specific system may have.

2. Write all of them down. Focus on the what of the system and not the how (the functionality, not the implementation).

3. Assign a unique ID to each one.

4. Link every ClickUp issue or issue ticket or unit test we have to a specific requirement (this functionality is a bit superfluous – ideally, the requirements tracking system can be linked to a certain verification step that, when complete, we can consider the requirement to be implemented).

5. If you want, you can even make certain categories of requirements. This may include regs-based requirements, MVP-definition requirements (what we consider to be necessary for delivering a successful minimum viable product), and extended requirements (extra stuff we can do after MVP or is not a priority).

Why do we need one?

Oftentimes, the problem I’ve seen with our vehicle is we have some arbitrary idea of a “complete product” without any deliverables that we can deliver to consider a product complete. This sort of links to our issue with timelining; if you don’t know what work needs to get done before competition, how will you set deadlines for tasks?

I think every system (perhaps even including mechanical systems, although I’m not super sure about their need for this) should sit down at the beginning of the build cycle and write down their requirements list for their system (hopefully in a requirements tracking system; if not, Excel is probably fine). This will:

1. Give system members a list of goals to complete by the end of the two year build cycle

2. Give system members a chance to read the regulations and brainstorm features for the system

3. Allow system leads to plan out timelines in a bit more granular detail

How can we get one?

I am not sure. Here are three options I thought of.

1. ClickUp may be a good place to start, with a list of tickets that serve as requirements and then are linked to by other systems. The benefit of this strategy is that you already have GitHub tracking and dependency completion in one platform. The drawback is that once ClickUp decides to put features behind a paywall (like it already does) you are screwed.

2. Some FOSS (Free and Open Source Software) Requirements Management System. Doorstop seems like it would easily integrate into existing GitHub workflow. Sphinx-Needs seems neat.

3. An in-house solution. This would probably be a whole separate project for whoever wants to pick it up (not me!) and is probably the best option long term if something stable gets off the ground. Northeastern Electric Racing has a similar project ongoing called FinishLine, which is more of a project management tool (similar to ClickUp for us) built in Typescript and React. It’s pretty sweet. I think a PM system and requirements system could be built into one in-house solution if this ever does happen.

At its core, FSGP is an efficiency challenge. With regards to the electrical system, that means maximizing energy generation and minimizing energy output. Furthermore, we want to minimize risk of failure. Thus, with this line of reasoning, the best course of action is to buy every system off-the-shelf and spend a short amount of time plugging and playing, and the rest of it racing the same car for 5-10 years. No sense in developing our own electronics if store-bought systems are less risky and more efficient.

At its core, LHRS (formerly UTSVT) is an embedded systems R&D club. At least, the electrical system is. Benefit to the members of the club is maximized by letting them take chances, make mistakes, get messy; especially with new and innovative ideas. This sort of new development takes more time, is inherently riskier and might be less efficient. Specifically, I want to highlight the time part. Integration issues will come up no matter what, so if you’re on a tight schedule you may be ending up living at the Pickle Research Center.

To balance both of these opposing ideas, we need to prioritize. Obviously we can’t swing too hard in either direction, or we can consider this experiment a failure.

1. First, get a car up and running with minimal features outside of what regulations requires. Your minimum viable product. Depending on how much risk you want to take on, this could be completely store-bought products like the Orion BMS or a Raspberry Pi/Arduino (although in my opinion this kind of takes the fun out of it). This could also be v1 iterations of our PCBs that do the bare requirements plus maybe a bit extra but not anything big.

2. Then, experiment. Build whatever your heart desires that would educate you, help the car in the long-term or short-term, and be fun.

This strategy has the best of both worlds. We both minimize risk and maximize member benefit.

Finally, don’t be married to any specific idea. As of the Summer 2024, our electrical design has stayed relatively static for (from what I can tell) the past 7, if not 13 years. It’s in our best interest to not rely on our past high level or low level design decisions, from overall system architecture all the way to component choice. Question everything and keep a critical eye, and make decisions based off of what would make for a better car AND a better member experience.

Remember, we will never run out of things to work on and a particular system is never “complete”, so dispel the notion that cutting features will cause a shortage of work, or that we will ever fully finish development early (because we won’t). There’s always new ideas and better designs that can be made.

This one is pretty simple. Figure out how big the car should be by doing calculations. Really the efficiency tradeoff of the whole thing seems to be # of array cells vs weight of car. That’s a bit of an oversimplification but certainly we can crunch a few numbers to find the sweet spot in terms of maximum array output VS weight of car.

We can also try to do a goldilocks method sort of thing and come up with example designs for three sizes: small, medium, and large. Then we can figure out numbers while having those ballpark weights & surface areas, and then choose the best range.

This is multiple suggestions (mostly relevant to Data Acquisition) rolled into one so I’ll list them out:

1. A robust CAN logging system with some Python GUI that’s easy to use is the perfect method of non-intrusive debugging. The dream is you’re able to have one connector from your laptop to the car and be able to record CAN traces with signal names and values, and have some GUI to see how different signals change over time. Then you can compare traces on a time series graph to pin down the specific issue. We can even implement redundancy by having the SD card in the LSOM also log this data, so you can pop the card into your laptop and see the CAN signals. You should be able to inspect traces in real-time or view a recorded log.

2. This is an idea from Polytechnique Montreal’s 2024 car Esteban 11. They have an LTE board (with a sim card) in the car that is sitting on the CAN bus for data acquisition. It streams the CAN signals to their server, which is then used as a database for an app they developed. All of their team members have this app and they can view the status of any of the car’s systems as well as the GPS location. This sort of thing is not technically difficult to develop, and is more useful than it may seem on first glance. During comp, your main bottleneck for debugging is time, so convenience is everything. The faster you can get the answer to what the problem is on the car, the better. I’ll cover this a bit more in the next section.

3. In the past we’ve used a CANdapter to connect to the CANbus from a laptop. This is a great tool; it translates our serial commands from a python script into CAN messages and can send/receive CAN messages so that we can simulate other systems.
   
   This may just be a neat idea rather than an actual issue, but now that we have a PSOM that has a microcontroller and hardware specifically for CAN, we can utilize it as a better version of a CANdapter. A significant flaw of the CANdapter is that all of the timed messages need to come from the laptop side; all of the hard timing requirements for simulated CAN messages are dependent on the accuracy of the Python timers and the serial output, which aren’t very accurate. In theory, we could use the RTOS timers on the PSOM and create some sort of interface which interprets messages that set up the periodic CAN messages on the hardware end.
   
   Basically, instead of running timers on the laptop and sending serial commands every X milliseconds, we’d send one serial command from the laptop over UART to the PSOM and it would set up the X millisecond timer.

JTAG is a pain in the ass in a production environment. On a bench it’s fine, but during integration and at the track it requires boards to be accessible for a debugger to be plugged in. Futhermore, GDB is an intrusive debugging method that may cause problems during integration (solution to this covered more in Improved CAN Tooling and Logging).

First, we do UART. This allows us to send a binary over UART while plugged into any single board’s UART output (which is a micro USB connector on the SOM). This method wouldn’t require a nucleo at all and would allow us to use UART for both reading printouts and flashing, which would be a time-save during bench testing.

But that’s not easy enough. With UART, you still have to have direct access to the board in question. To update firmware on any board in the car, it would be easiest if the programmer could plug in one connector on the car to their laptop and choose a board to flash. Then, the binary could be sent over CAN and be picked up by the board that needs to be flashed. This would require some custom bootloader development especially since for PSOMs we’d have to redirect the binary from the leader to the peripheral (since everything is not on the CarCAN bus).

STM32 F4 and L4 both have a built in UART and CAN bootloader that we could experiment with to get a first start.