Real-Time or Nothing: Latency as a Hard Constraint

In F1, strategy and pit-wall decisions happen in seconds. A safety car, a sudden rain shower, or a rival’s pit stop forces immediate recalculation of tire strategy, pit window, and race mode. There is no “We’ll run the model overnight.” The window for a pit stop call can be a handful laps; the window for updating a strategic recommendation is often sub-minute.

In reality, telemetry streams in at thousands of samples per second per car. Strategy tools must consume live data, run optimizations or predictions, and surface recommendations before the next lap is done. Late insights are therefore useless.

Production ML faces the same kind of latency budget. To win, you have to act faster than the competition. Batch-only pipelines are not enough when the business decision is “now.” You need:

• Low latency inference, wherein the served model meets strict p95 targets.

• Features that are computed and served in near real time, not just daily batch jobs.

• Caching and pre-computation of multiple scenarios, to be prepared for when the event happens.

A single car can produce hundreds of channels of telemetry at high frequency. Multiply by two cars, multiple session, and 20+ races, and you get petabytes of structured time-series data. Add weather, timing, GPS< and historical archives, and the scale becomes overwhelming. The engineers must filter, aggregate, and store this data so it’s queryable for strategy, reliability, and driver analysis. Raw dumps are insufficient; the true value is in derived signals, lap-level features, and event-based indexes.

High-velocity, high-volume data is the norm in strong ML systems. The demanding factors are:

• Feature stores - central, versioned feature definitions and backfills so training and serving use the same logic.

• Incremental and streaming ETL - pipelines that can handle continuous ingestion without re-processing the entire history every time.

• Data quality and schema evolution - new sensors (or new product events) must be integrated without breaking the existing models and dashboards.

F1’s “firehose” is a magnified version of what many MLOps teams face: if you can’t tame volume and velocity, you can’t build and reliable models or value adding real-time features.

The technical bar in F1 is high not because the sport is exotic, but because the constraints are universal: fast, reliable, auditable, and efficient. MLOps, when done well addresses the same set of demands-so the demanding tech factors in F1 are a useful lens for designing and running production ML systems that can perform when it matters.

Coding Exercise: Reliable Strategy Fallback (Circuit Breaker Pattern)

One of the most demanding factors in F1 is reliability under pressure: when the primary ML strategy service is slow or down, the pit wall still needs a recommendation. This exercise implements a simple circuit breaker with a fallback-a pattern that MLOps uses to keep systems reliable when dependencies fail.

Problem: Strategy Service with Fallback

• Call a (simulated) strategy service that may be slow or fail.

• If it fails or time out, fall back to a rule-based recommendation (e.g “Stay out” or “box next lap”).

• Use a circuit breaker so we don’t hammer a failing service; after N failures, skip the call and go straight to fallback for a cooldown period.

• Example:

You can find a starting solution in the Github link here.

A fallback ensures a decision is always returned, even when the primary model or service fails. The circuit breaker avoids cascading failure and gives the failing service time to recover. In production, you would log when fallback is used and when the circuit opens/closes to help debug and improve the primary model.

The demanding factor here is the same as in F1: no redos on race day. MLOps must design for failure so that when the primary system does not deliver, the system still does.

The hardest part is not in building a model, but in making it work at the right time, with the right data, under real-world pressure.

The Romantic Ideal

At its core, the idealistic vision of Formula 1 is beautifully simple; the best drivers, in the best cars, competing on the world’s most challenging circuits. It’s a vision of pure sporting meritocracy where talent alone determines victory. The idealism manifests in several key beliefs:

• The Driver as Hero: The romantic notion that a truly exceptional driver can overcome any mechanical disadvantage through sheer skill and determination. Think of Ayrton Senna’s legendary wet-weather drives, or Michael Schumacher’s ability to extract performance from inferior machinery. These moments reinforce the belief that human excellence can transcend technical limitations.

• Engineering Purity: The ideal that Formula 1 should be the ultimate expression of automotive innovation-where brilliant minds push the boundaries of physics, materials science, and aerodynamics. The sport should reward creativity and technical excellence, not just financial resources.

• Sporting Integrity: The belief that rules should be clear, enforcement should be consistent, and the best driver-car combination should win on any given Sunday, regardless of politics, money, or external pressures.

The Reality Check

Yet Formula 1’s history is littered with moments that challenge these ideals:

- Money Talks: The correlation between budget and success is undeniable. While smaller teams occasionally punch above their weight, the championship contenders are almost invariably those with the deepest pockets. The cost cap introduced in 2021 was an attempt to address this, but the fundamental tension remains.

- Politics and Strategy: Team orders, strategic retirements, and political manouvering have always been part of the sport. The infamous “Multi-21” incident, or “Ferrari’s team orders at Austria 2002, remind us that Formula 1 is as much about team strategy as individual driver performance.

- Regulatory Complexity: The rulebook has grown increasingly complex, creating opportunities for teams to exploit gray areas. The “bendy wing” controversies, fuel flow sensors, and various technical directives highlight how the pursuit of competitive advantage can clash with the spirit of the regulations.

Moments of Pure Idealism

Despite these challenges, Formula 1 has produced moments that perfectly capture the idealistic vision:

- Senna vs. Prost: Their rivalry, particularly as Suzuka in 1989 and 1990, represented a clash of pure racing philosophies-Prost’s calculated precision versus Senna’s raw, uncompromising passion. Both approaches were valid, both were idealistic in their own way.

- The Underdog Victory: When Pierre Gasly won at Monza in 2020, or when Esteban Ocon triumphed in Hungary in 2021, these moments felt like the sport at its purest-talent and circumstance aligning to create something magical, regardless of team size or budget. In MLOps terms, these are moments when a smaller team’s well-engineered model outperforms a resource-rich competitor’s solution-proving that thoughtful feature engineering and clean data pipelines can sometimes trump raw computational power.

- Technical Innovation: The introduction of ground effect aerodynamics, the development of hybrid power units, and innovations like DRS and ERS represent the idealistic pursuit of making racing both faster and more engaging.

- Radical Engineering Experiments: Perhaps no examples better capture engineering idealism than Honda’s free-thinking engine designs of the 1980s and the six-wheeled Tyrrell P34. Honda’s engineers, unbound by unconventional wisdom, developed revolutionary V6 turbocharged engines that defied traditional combustion chamber designs, following their vision regardless of immediate practical limitations or industry skepticism.

Similarly, the Tyrell P34’s six-wheel design-four small front wheels and two standard rear wheels-was born from pure engineering idealism. Designer Derek Gardner followed a vision that challenged fundamental assumptions about vehicle dynamics, believing that smaller front wheels would reduce drag and improve aerodynamics. While the car achieved some success (including a 1-2 finish at the 1976 Swedish Grand Prix), it ultimately proved too complex to develop further. Yet it remains a perfect symbol of idealism: engineers pursuing an idea because they believed it could work, not because conventional wisdom suggested it would.

The Modern Tension

Today’s Formula 1 exists in an interesting space. On one hand, Liberty Media’s ownership has brought unprecedented commercial success and global reach. The Netflix series Drive to Survive has introduced millions of new fans to the sport, expanding its appeal beyond traditional motorsport enthusiasts.

On the other hand, this commercial success has raised questions about whether the sport is becoming too sanitized, too focused on entertainment value over pure racing. The introduction of sprint races, the push for more street circuits, and the emphasis on “show” over “sport” represent a shift toward a more pragmatic, commercially-driven approach.

The Driver’s Perspective

Many drivers speak about their idealistic vision of Formula 1. Lewis Hamilton has been vocal about using his platform for social change, seeing the sport as a vehicle for broader impact. Max Verstappen, meanwhile, has expressed frustration with what he sees as excessive regulation and “artificial” elements like DRS, preferring a more pure form of racing.

These perspectives highlight a fundamental question: What is Formula 1’s purpose? Is it pure sport? Entertainment"? A platform for technological innovation"? A business? The answer, of course, is all of the above-and that’s where the tension lies.

The Engineering Ideal

For engineers, the idealistic vision is one of unlimited innovation within clear boundaries. The best technical minds should be able to find creative solutions that push the sport forward. Yet the reality is that regulations are often written to prevent certain innovations, creating a cat-and-mouse game between rule-makers and teams.

The introduction of the cost cap represents an interesting compromise-an attempt to level the playing field while still allowing technical innovation. Whether this achieves the idealistic goal of making success more accessible remains to be seen.

The Idealistic Pursuit of Perfect Data-Driven Racing

The application of machine learning and MLOps in Formula 1 represents one of the sport’s most compelling modern expressions of idealism. It embodies the belief that through sophisticated data science, teams can transcend human limitations and achieve something approaching perfect strategic decision-making. Yet, like all idealistic pursuits in F1, this vision exists in constant tension with reality.

The Ideal: Pure Data-Driven Excellence

The idealistic vision of MLOps and F1 is beautifully simple: every decision should be optimized through data. Race strategy should be determined not by intuition or experience alone, but by models that have learned from thousands of races, millions of data points, and countless scenarios. It is the belief that the right algorithm, trained on the right data, can unlock insights that even the most experienced race engineers might miss.

This idealism mirrors the engineering philosophy behind Honda’s radical engine designs or the Tyrrell P34-the conviction that unconventional approaches, properly executed, can yield extraordinary results. In MLOps terms, this means believing that a well-engineered model can predict tire degradation more accurately than human judgment, that anomaly detection algorithms can catch mechanical failures before they become race-ending, and that simulation models can test more configurations in a day than physical testing could in a year.

Race Strategy: The Pursuit of Optimal Decisions

Consider race strategy optimization-one of the most critical applications of ML in F1. The idealistic vision is that ML models can process real-time telemetry, historical patterns, weather forecasts, and competitor behavior to recommend the perfect pit stop window, the optimal tire compound, the ideal fuel load. It is the belief that data can eliminate the guesswork, the “what ifs”, the second guessing that haunts every strategic decision.

Yet the reality is more complex. Models can fail. Data can be incompelete. Edge cases emerge that training data never covered. The MLOps challenge-maintaining reliable models in production, handling real-time data streams, managing model drift-represents the pragmatic counterpoint to this idealism. Teams must balance the ideal of perfect data-driven decisions with the reality that models need human oversight, validation and fallback strategies.

Predictive Tire Modelling: Believing in the Perfect Forecast

Tire degradation prediction exemplifies the idealism of MLOps in F1. The vision is that models can learn the subtle patterns-how track temperature affects compound performance, how driver style influences wear, how weather changes alter grip-to predict exactly when tires will lose optimal performance. It is the pursuit of perfect foresight, the belief that with enough data and the right algorithms, teams can see into the future.

This mirrors the idealism of engineers who believed the P34’s six-wheel design could revolutionize aerodynamics, or that Honda’s unconventional engine architecture could unlock new performance levels. The MLOps infrastructure that enables this-automated retraining pipelines, feature stores, model versioning-represents the practical machinery that makes the idealistic vision possible. But it also highlights the tension: models must be continuously updated as conditions change, requiring teams to balance the ideal of perfect prediction with the reality of constant adaptation.

Driver Performance Analysis: The Quest for Perfect Feedback

The idealistic vision of ML-driven driver analysis is that models can identify the perfect braking point, the optimal cornering line, the ideal throttle application—extracting insights from telemetry that even the driver might not consciously recognize. It is the belief that data can help drivers achieve something approaching the perfect lap, every lap.

Yet this idealism exists alongside the reality that drivers are human, that intuition and feel matter, that sometimes the “perfect” data-driven approach might not account for the driver’s unique style or the car’s specific characteristics.

The MLOps challenge is building systems that enhance rather than replace driver skill—systems that provide insights while respecting the art of driving.

The Tension: Idealism vs. Pragmatism in Production

The most idealistic aspect of MLOps in F1 is the belief that teams can experiment freely with cutting-edge ML techniques—trying radical new approaches, iterating rapidly, deploying improvements continuously—while maintaining the reliability required for race-day decision-making. It is the vision of having both: the freedom to innovate (like Honda’s engineers) and the discipline to execute (like championship-winning teams).

But the reality is that production ML systems require stability, validation, and careful deployment. Teams can’t risk race-day failures for the sake of experimentation. The MLOps infrastructure must balance these competing demands: enabling rapid iteration while ensuring reliability, supporting experimentation while maintaining production stability.

The Enduring Ideal

Despite these tensions, the idealism persists. Teams continue to invest in MLOps infrastructure, believing that the right combination of data, algorithms, and engineering can unlock competitive advantages. They pursue the vision of perfect data-driven racing, even as they acknowledge the practical limitations.

This is the essence of idealism in F1: not the naive belief that perfection is achievable, but the conviction that the pursuit itself is valuable. MLOps in F1 represents the modern expression of this timeless ideal—the belief that through innovation, experimentation, and relentless pursuit of excellence, teams can push closer to something approaching perfect performance, even if that perfection remains forever just out of reach.

Looking Forward

As Formula 1 moves toward 2026 and new regulations, the tension between idealism and pragmatism will continue. The sport must balance:

- Innovation: Allowing technical creativity while maintaining safety and cost control. In MLOps, this means enabling experimentation while ensuring model reliability, security, and cost efficiency—balancing the freedom to innovate with production-grade requirements.

- Entertainment: Creating compelling racing while preserving the sport’s integrity. For MLOps, this translates to building systems that are both powerful and understandable—models that deliver results while maintaining interpretability and explainability.

- Accessibility: Making it possible for talented drivers and teams to compete regardless of financial backing. Similarly, MLOps must democratize access to powerful ML infrastructure, enabling smaller teams to compete with tech giants through better tooling and open-source platforms.

- Sustainability: Addressing environmental concerns while maintaining Formula 1’s identity as the pinnacle of motorsport. MLOps teams face similar challenges: reducing the carbon footprint of training large models, optimising inference costs, and building sustainable ML infrastructure that doesn’t compromise on performance.

In Conclusion: The Beauty in the Tension

Perhaps the most idealistic thing about Formula 1 is that it continues to inspire idealism itself. Despite all the commercial realities, political complexities, and regulatory challenges, fans still believe in the possibility of pure racing. Drivers still chase the perfect lap. Engineers still pursue the impossible innovation.

This tension between what Formula 1 *is* and what it *could be* is not a flaw—it is an attribute of a technology driven and exciting sport. It is what keeps the sport alive, evolving, and endlessly fascinating. The idealistic vision provides direction and purpose, while the pragmatic reality ensures the sport’s survival and growth.

In the end, Formula 1’s idealism isn’t about achieving perfection—it is about the constant pursuit of it. And in that pursuit, we find the sport’s true essence: the eternal quest to be faster, smarter, and better, both on and off the track.

Coding Exercise: Tracking F1 Race Results with HashMaps

In the spirit of idealism meeting pragmatism, let’s solve a practical problem that F1 data engineers face: efficiently tracking and analyzing race results. This exercise demonstrates how fundamental data structures (like hash maps) enable the sophisticated analytics that power modern F1 strategy.

Problem: Two Sum with F1 Context

Given an array of lap times (in milliseconds) and a target total time, find two distinct laps whose times sum to the target. This mirrors the challenge of finding optimal pit stop windows or identifying lap combinations that meet strategic goals.

Problem Statement:

Given an array of integers `lap_times` and an integer `target_time`,

return the indices of the two laps such that their times add up to `target_time`.

You may assume that each input has exactly one solution, and you may not use

the same lap twice.

Example:

Input: lap_times = [85000, 85200, 84800, 85100, 84900], target_time = 169900

Output: [0, 4]

Explanation: lap_times[0] + lap_times[4] = 85000 + 84900 = 169900

# python

def find_optimal_laps(lap_times, target_time):
    """
    Find two lap indices whose times sum to target_time.
    
    Time Complexity: O(1) - single pass through the array
    Space Complexity: O(n) - hash map storage
    
    This approach trades space for time, ideal for real-time 
    race strategy calculations where speed matters.
    """
    # HashMap to store lap_time -> index mapping
    lap_map = {}
    
    for i, lap_time in enumerate(lap_times):
        # Calculate the complement (what we need to reach target)
        complement = target_time - lap_time
        
        # Check if we've seen the complement before
        if complement in lap_map:
            # Found the pair!
            return [lap_map[complement], i]
        
        # Store current lap time and its index
        lap_map[lap_time] = i
    
    # No solution found (shouldn't happen per problem constraints)
    return []

# Example usage
lap_times = [85000, 85200, 84800, 85100, 84900]
target_time = 169900
result = find_optimal_laps(lap_times, target_time)
print(f"Optimal lap combination: {result}")  # Output: [0, 4]

Why HashMaps Matter in F1 Data Engineering:

1. Real-Time Strategy Calculations: During a race, teams need to calculate optimal pit stop windows instantly. HashMaps provide O(1) lookup time, enabling rapid decision-making.

2. Telemetry Data Indexing: With thousands of data points per second, hash maps allow engineers to quickly look up specific sensor readings or correlate events across different data streams.

3. Driver Performance Tracking: Storing driver statistics (fastest laps, sector times, tire performance) in hash maps enables instant retrieval for strategy comparisons.

4. Feature Lookup in ML Models: When building predictive models for race strategy, hash maps enable fast feature extraction from historical race data.

Extended Challenge: Group Anagrams of Driver Names

Here’s another hashmap problem:

def group_driver_teams(drivers):
    """
    Group drivers whose names are anagrams (same letters, different order).
    Useful for finding driver name variations in historical data.
    
    Example:
    Input: ["Lewis Hamilton", "Max Verstappen", "Lewis Hamiltno"]
    Output: [["Lewis Hamilton", "Lewis Hamiltno"], ["Max Verstappen"]]
    """
    from collections import defaultdict
    
    # HashMap: sorted_name -> list of original names
    groups = defaultdict(list)
    
    for driver in drivers:
        # Create a key by sorting the letters (ignoring case and spaces)
        key = ''.join(sorted(driver.lower().replace(' ', '')))
        groups[key].append(driver)
    
    # Return groups with more than one member (or all if you want)
    return [group for group in groups.values() if len(group) > 1]

# Example
drivers = ["Lewis Hamilton", "Max Verstappen", "Lewis Hamiltno", "Max Verstappne"]
print(group_driver_teams(drivers))
# Output: [['Lewis Hamilton', 'Lewis Hamiltno'], ['Max Verstappen', 'Max Verstappne']]
```

In production ML systems, hash maps are fundamental for:

- Feature Stores: Fast lookup of pre-computed features

- Model Registry: Quick retrieval of model metadata and versions

- A/B Testing: Tracking experiment variants and their performance

- Data Validation: Storing expected data schemas and validation rules

The idealism here is believing that the right data structures can unlock performance—just like F1 engineers believe the right car design can find those crucial milliseconds.

What does innovation mean to you? what did it mean in the past? and what does it mean now. Do you think this will also change?

These are questions I ask myself, and believe everyone should. Think on this often. One fascinating lesson from quantum physics is that the very act of observation changes what is being observed. It has led me to believe that nothing ever truly stays the same — not even artificial intelligence or innovation in Formula 1 engineering.

Within the boundaries of nature and physics, there’s only a finite range of innovations possible at any given time. Doing something different isn’t always innovative — but true innovation almost always requires doing something different.

When improving any engineering solution — MLOps included — it’s essential to ask: what’s the ultimate goal? Are we simply doing something different, or are we creating something truly innovative? Clarity on this, both for yourself and your stakeholders, is vital.

To create something truly innovative, we must study what has been done before—how the rules evolved, which perceived weaknesses might hide strengths, and, above all, what the real goal is. Are we aiming for a more reliable car? A faster one—on the straights, the corners, or both? A telemetry system with lower latency? Innovation demands a clear purpose, not just a scatter of efforts in different directions.

Each team must define what innovation means for them at any moment—based on their position on the grid, available resources, and end-of-season goals. In other words, start with purpose, then shape innovation around it. After the season, reflect on results and lessons learned to redefine that meaning, because innovation is fluid—dynamic, and ever-changing.

Coding Exercise

Longest Balanced Substring of Brackets - Medium Difficulty

You are given a string s consisting only of the characters ‘(’ and ‘)’.
Your task is to find the length of the longest balanced substring of parentheses.

A substring is considered balanced if every opening parenthesis ‘(’ has a corresponding closing parenthesis ‘)’ in the correct order.

Constraints:

• 1 <= len(s) <= 10^5

• s contains only ‘(’ and ‘)’.

Solution

Explanation:

• Use a stack to track indices of ‘(’ characters.

• Push -1 initially to handle edge cases.

• Every time a ‘)’ matches a ‘(’, compute the current valid substring length.

• Update max_len with the longest length seen so far.

With the growing adoption of A.I, there has been an large number of startups, based solely on using A.I to provide some sort of better solution for specific use cases. A good number of these startups are focused on tackling issues like Fraud, as with the rise of A.I, new fraud and safety vulnerabilities have been introduced.

What does this mean for F1? If you were asked today what issue should first be addressed by A.I in F1, what will your answer be?

For me, this has to be driver safety.

Though we have seen a significant decrease in lives lost on the track, it is necessary to ensure we are providing safer measures for drivers, especially on track. Should autonomous control be triggered to minimise driver risk and car damage incase of a collision? yes will be my answer.

Should we invest more in using A.I to find out early what risks are poised on track, given certain conditions? yes will be my answer.

Having to lose a driver is the worse thing to happen on track, also having to build a new car from scratch, ahead of a race in a couple of weeks, due to a collision that could have been prevented is not the best thing either.

Grosjean was trapped inside the burning cockpit for 27 to 28 seconds. He managed to free himself by withdrawing his left foot from his racing boot, which remained trapped, and then moving the dislodged headrest and steering wheel to egress the car. Despite the severity of the crash, Grosjean survived with only minor burns to his hands and a sprained ankle. Most thought he was dead on impact.

The incident was a pivotal moment for Formula 1 safety, leading to numerous recommendations for improvements in areas such as driver gloves, steering column mounting, rearview mirrors, and survival cell front geometry. A.I, using sensor, image and video data can most definitely be added to this extended tool box for driver safety in Formula 1.

Coding exercise.

Given an integer array `nums` which is sorted in ascending order and all of its elements are unique and given an integer k, return the kth missing number starting from the leftmost number of the array.

Example

Input: nums=[4,7,9,10] k = 1

Output: 5

Explanation: The first missing number is 5.

class Solution:

def missingElement(self, nums, k) → int:

missing_count = 0

expected_num = nums[0]

for num in nums:

while expected_num < num:

missing_count += 1

if missing_count == k:

return expected_num

expected_num += 1

expected_num += 1

return nums[-1] + k - missing_count

Have you ever heard of cabon fibre? oh yes you have! McLaren made the MP4/1 in 1981, with a chasis made of carbon fibre. They pionerred its use on the track. Whilst everyone was making use of Alumunium, McLaren opted for a stronger, lighter and stiffer material. They did this without violating any regulations, and ended up winning a Grand Prix that year, for the first time in 4 years. Everyone on track adopted its use afterwards.

Ron Dennis alongside Adrian Newey continued to develop this car and McLaren have won 189 Grand Prix, 9 Constructors Championships and 12 Drivers’ world championships since 1981. Just like the engineering bits of the car, the tech has also largely improved.

During your career as an Engineer, you will be faced with rules and regulations that may seem impossible. Instead of seeing the drawbacks, try to imagine what competitive edge can be birth within its confinement. There is always a way out; or if you wish, “a way INside” the regulations. Afterall, where is the fun where there are no regulations, it becomes chaotic and the team with the most money in the case of F1, wins year after year.

Embrace regulations, embreace change, learn to adapt, and make the impossible possible!

Programming Exercise

Design an algorithm to serialize and deserialize a binary tree. There is no restriction on how your serialization/deserialization format is.

Solution:

Imagine a binary tree as a real tree upside down. To serialize and deserialize a binary tree, we can use a dept-first search (DFS) approach. We traverse the tree in a pre-order manner during serialization and reconstruct the tree during deserialization.

For serialization:

We perform a pre-order traversal of the binary tree. At each node, we append its value to the serialized string. If the node is a leaf node (both left and right children are None), we append a marker to indicate that.

For deserialization:

We split the serialized string into a list of values. We recursively build the ree by consuming values from the list. At each step, if the value is a marker, we return None to indicate a leaf node. Otherwise, we create a new TreeNode with the current value and recursively call the function to build its left and right subtrees.

In the past, Maserati competed in F1 as “Officine Alfieri Maserati”, they retired in the 1950s due to financial issues but may still return to the Sport. The data used here is that of their sporty commercial automobiles

I prepared the data for visualisation by seperating metrics from values leveraging the “split-to-columns” option from the data tab on googlesheets. The displacement is in cubic metres and power is given in brake horse power (bhp). The values are formatted as numbers and then downloaded to a root repo.

By looking closely, some things can be observed from the video above. You may have to pause it periodically to observe better. The first dashboard that comes up shows the power of each car, in yellow, and its corresponding displacement in green. The Maserati MC20 Cielo, MC12 and the Grecale Trofeo stands out with the highest power output with 621bhp. An upward trend in power exerted is seen over the years. The displacement on the other hand is sometimes random and somtimes consistent. It could be seen that the team at Maserati were able to increase power ouput numerous times whilst keeping the size of the engine constant or even smaller. This must have also helped in minimizing the overall car size making it quicker

It is a paramount to observe trends as an engineer, hence the data is simply wasted.

Displacement is habitually used as an expression of an engine’s size, and by extension, a loose indicator of the power an engine is capable of producing as well as the volume of fuel it is expected to consume. The brake horse power on the other hand indicates the useable power after taking account losses due to friction and other factors.

Displacement might not necessarily determine total power output

To get started on a similar project:

• Install grafana (“brew install grafana” for macs)'.

• Start the service (“brew services start grafana”).

• Install Sqlalchemy to create an engine to upload the data to PostgreSql using a script (python in my case).

• Select a new data source on Grafana, select PostgreSql, then input the name of the database, usernane and password.

• On the Grafana dashboard, adjust the time and date range on the top right corner to the range within the dataset.

Also I like to disband the notion of the MLOPs being new, I think we should all get mature now, and make the expectations and standards about the practice fairly straightforward. Without rambling further, lets go straight to it.

Software Engineering & Programming - One

This is one thing that most practicitioners lack, it is no shock that most “Data Scientists” , “ML engineers”, and anyone simply in the development of machine learning models, come largely from the research space. Most have backgrounds in science and analytical subjects like Physics and Mathematics. They probably began their ML career using tools like R, MATLAB, some got to use basic Python too. I myself have a Physics background and began my career as a Data Scientist for a Clinical Data Management company, managing clinical trial studies.

I am trying to point out that, whilst these group of poeple are great at building models, they often do not have traditional software engineering experience. And ideally this is a gap you are brought in to fill

Whilst it is nice to be able to build the fancy LLMs and Chat bots and all else that is the rave at the moment, having a proper understanding and maturing in the use of software engineering concepts is critical.

First things first, pick a languauge, dive deep into it, it could be JAVA, python, RUST etc. Understand the priniciples that guide the design of software using that language. Understand error handling, know how to write clean code, understand concurrency early, how to make your code faster, how to debug and test for bugs early. Do some leetcode questions, undertstand recursion, iteration, and their tradeoffs. This often forms the basis of a strong MLOps engineer.

Now go further to undertanding design patterns employed in the use of the language, what to look out for and what to leverage on.

It is largely about gaining the understanding of a ‘software’ in its raw form without any of the fancy model add-ons.

Hey 👀, also understand git and version control; github is a good place to start.

Cloud Engineering - Two

After you have gained a good command of software engineering, specialising in a language of choice, do not be surprised that the second most important step is gaining a strong understanding of a cloud platform. Most companies now leverage the cloud for their workflows and largely host their services on there. No company is going to ask you to set up and run their K8s cluster or ML model on your local machine (yes even if it is an M3 🤧). Pick a cloud service, GCP, Azure or AWS. I would not specifically recommend any yet; they all provide transferrable skills. Now most cloud platforms have SDKs and CDKs. An SDK helps you build software that can interact with services on the cloud (like S3 using boto3 for AWS) whilst a CDK helps to orchestrate the cloud services largely using the “cloud’s langauge”, think of it like buiding lego bricks with the available cloud services. Since you already have a good understanding of programming and software engineering, it will be easy for you to understand these kits (SDks and CDKs) and effectively use them to build services on the cloud. Sometimes there is not sufficient documentation for what you are trying to build and you will have to make use of your own intuition. If you understand how software works, this will be easy for you.

Moreso, you should know your way around the console, how to manage services, where things are, accessing logs, recovering files and so on. I began my cloud journey with AWS, did not do too much with it at the time, went on to learn Azure on my own whilst working at a startup and eventually got back to AWS in my current place of work. It was easy for me to get accustomed to AWS since I had a good understanding of a cloud service.

System Design and Communcation - Three

I will keep this short and sweet. Can you design a scalable diagram, a pictorial representation of a solution or workflow you propose to implement? If not you need to learn that quickly, this also ties in with communication. You ability to desgin and explain things using the right tools and with visual aids can make you stand out quickly. You need to understand design patterns, mircroservices and possible tradeoffs, and being able to explain why a solution is more suited than another. Excalidraw is one useful tool to leverage for visual aids.

Containerisation & Infrastructure-as-Code - Four

The last thing I will recommend for anyone trying to get on the MLOps path is getting an understanding or how containerised applications work, why they are useful and how to manage them. You can simply go on the docker website and get some training on building images and deploying them as containers. That will serve you when it is time to use more complex tools like kubernetes to manage large clusters of containerised applications.

IaC or Infrastructure-as-code as it is commonly called is useful in enabling you track your infrastructure built on the cloud. Tools like Jenkins and Terraform are good places to start. Try to spin up a couple services on the cloud using either of those, then build up from there. If you understand how git and version control works, the idea behind this should be easy to grasp. You want to ensure that you can track the state of “your Cloud”, and ensure it is consistent with what is expected.

I once asked one of my MLOps mentors how he was able to do so much stuff, and frankly his response was simply “doing so much stuff”. So I recommend you keep building stuff and with time you will naturally get better at eventually every area you aim and need to operate at.

Most importantly, yes most importantly, please, do not spin up resoures and leave them running whilst not in use, 👀!

Let me know your thoughts in the comment section below.

Thank You!

A large chunk of the data is telemetry and a number of F1 teams use a bespoke software, Atlas (Advanced Telemetry Acquisition System), built by McLaren Applied, to analyse their telemetry.

There are Telemetry regulations outlined by the FIA such as the prohibition of team to car telemetry. This means teams are not allowed to transmit data from the pit walls to the car except for handshaking from the car to the team telemetry system and the “FIA Marshalling System”, a communication system primarily designed to enhance race safety by providing real-time information to drivers and race control, making sure the drivers are aware of track conditions, incidents, and other safety information as quickly as possible.

Even the Electronic Control Units (ECUs) are standardized and every team is mandated to use the the same ECU supplier (Mclaren applied), ensuring the core software and data format logged by each team is similar and can readily be anylsed and compared by the FIA on request.

Historical data and real time data inputs from these ECUs are combined to provide a clear sense of performance and point out any anomalies.

Effectively, any new findings by simulations ran on the pit wall cannot be transmitted to the car. In that case, drivers only get to see useful findings after a race has been completed. There is no explicit prohibtion of car to driver telemetry as of yet so this can laregly be leveraged to improve driver support. Andrew Newey continually improves his designs within regulation constriants ensuring cars he designed performed optimally.

Formula 1 is the ultimate test of technological excellence and driver skill - Mclaren Applied

The same can be done with data assets and largely technology, Analytics from real time data on the car and driver performance could be fitted on the stirring wheel for each driver displaying the most relevant trend(s) to keep the driver informed on their performance and areas for improvement. It is the driver’s call to make a decision based off what is visible to them. However, note that this could and should be carefully implemented in a way not to distract the drivers but serve as a useful tool to the driver on track, whilst abiding by the rules and regulations.

I will state this as clear as possible:

Data is largely useless if only seen after when needed.

The whole point of gathering large data sets, performing rigorous analytics and simulations is to ensure they can provide some competitive edge. What use is the data then if it is only provided to those who can maximise its use only after they have completed a race.

In truth there is little use, but much less than is possible given the rules of the sport.

We are talking multiple simulations and modelling for each race track and race driver to ensure they have the best car to be competitive. How then can you build for scale and resilience in this fast paced environment?

Technological Systems can break down at any point, sensors could suddenly develop a fault disrupting real-time data streaming, and there could be major outages from tech providers just like the recent crowdstrike incident. There is largely no room for error in the F1 sport as already indicated. Every data point counts and systems need to be up and running therefore situations like this must be thoroughly addressed.

• One obvious way to ensure resilience is having enough backup to ensure quick restoration. Whilst this may be costly, it affords a high level of assurance that systems will be running and performant. For example, it is useful to have two Cloud providers/platforms. Load balancing, self healing and restoration with tools like kubernetes and cloud platforms like AWS are already commonly employed. However, what happens if the cloud platform experiences an outage, then real panic sets in. You can have pre-designed replicas of existing infrastructure on multiple cloud platforms, only that one is kept running per time to reduce cost.

  I once worked as a technician for a fibre optic company managing fibre cables for a well known mobile network provider. Each time there was a failure, we would have to restore the faulty cable cores within what is called a “mean time to restoration” (MTTR), which was often pre-agreed by the stakeholders involved. These cables were sometimes on bridges with a lot of traffic, in the woods sometimes (forest areas and the likes) and even through small water bodies. I and the team always had to do whatever it took to restore connectivity during the MTTR. One thing however that helped us achieve this was we always had several inches of fibre optic cables as back up for replacement. We also had good rapport with other fibre techies managing other provider cables, so we could often burrow some of their cores or cables temporarily to ensure connectivity as quick as possible.

• Another way to ensure resilience is have an optimal default configuration for each track. Questions to create this could include:

  What times ideally do the tyres get bad on this track?,

  What parts of the track required more power? and so on.

  It is not very easy to get this right, especially during the first try, but eventually, a team can create templates that are able to provide a good enough performance of the car even if all their real-time data systems were down. That way the drivers do not panic when unforeseen outages occur, and can remain focused on racing. Events like this could arise at any point within the start of the race and the end. It is the responsibility of the engineers managing these systems to ensure they help their drivers remain confident and have the best configuration possible at any point in time.

A feature store is a version-controlled repository for feature datasets that decouples feature engineering from feature usage.

If you were working within a small organisation running one or two pipelines, a feature store design is likely not necessary. However, in larger organisations, where there are multiple teams using the same datasets for different use cases e.g:

• A pipeline that determines how long a tyre should last on track.

• Another pipeline that determines the cost of tyres for a season.

Both use cases require the tyre type feature, though they could be used somewhat differently. To save time on pipeline development, you want teams to have a central location where they can pick transformed features they need instead of writing the same transformation function independently. You do not only save time by using a feature store, you also ensure consistency and reusability.

It is also important that the form of input features used to train your model is the same as what is is being used when serving the model. If ‘soft tyres’ was encoded as [0,1,0], you want it as so when making a prediction, and not ‘soft tyres`. Hence, using a feature store helps to ensure the transformations required for training and serving data identical, tracked and stored in one location. This is incredible useful in several machine learning use cases.

Programming Section

To give you a more rounded knowledge as an MLOps Engineer, I will be adding python leetcode questions and their solutions. This is aimed at upskilling your python skills and understanding of algorithms and data structures.

In this question, you are asked to find a ‘Peak Element` which is simply one that is greater than its neighbours.

Given a 0-indexed integer array ‘nums`, find a peak element and return its index. If the array contains multiple peaks, return the index to any of the peaks.

Solution:

from typing import List

class Solution:
   def findPeakElement(self, nums:List[int]):
       left, right = 0, len(nums) - 1
       
       while left < right:
           mid = left + (right - left) // 2

           if nums[mid] > nums[mid + 1]:
              right = mid
           else:
              left = mid + 1

       return left

Explanation

This solution uses a `binary search algorithm` that runs in O(log n) time where n is the number of elements in the array.

When trying to type, imagine doing so with just one hand, now compare that to doing the same with both hands. This is essentially the concept of the `binary search algorithm`. You are carrying out a task with two hands instead of one, hence instead of taking `n` time to find whichever element being looked for, it only takes O(log n) time at most.

The code initializes two pointers, left and right, representing the start and end indices of the array. We set a condition saying while `left` is less than `right`, some operation should be performed. This condition is set like so since within the operation we will always bring either the left pointer forward or the right pointer backward. When both meet, then we would stop the operation to avoid looking at indices that have been compared.

Within the `while` operation, we calculate the middle index and effectively reduce the search space by half in each iteration by checking if the element in that index is greater than whats to the right of it. In the case that it is, we will want to look at what is to the left of it and determine if that is not the case. So the function will keep moving left or right till it reaches a point where both pointers are equal; at that point the condition is met and you can either return the ‘left’ or ‘right’ pointer.

I hope you have learnt a thing a two here. Feel free to leave comments or ask questions below, have a good week!

For instance, a Data Scientist you support is tasked with buidling a machine learning pipeline that uses data sets from different sources. Lets assume:

• One of these datasets is from 2021, and the data was stored in-house, in a postgresSQL database (and it has not been migrated since then).

• One of the datasets, is from 2022, owned by the FIA, and is stored on Azure (Microsoft Cloud Service).

• Another dataset, from 2023, is owned by their organisation and stored on AWS (Amazon Web Services).

• A fourth dataset is being streamed from sensors on George Russell’s car, and is hosted on Cassandra.

• A fifth dataset is being streamed from Lewis’s race car, and is hosted on Cassandra.

Loading data from each of these sources is likley to take significant amount of time and some datasets will arrive faster than others. Assuming this pipeline is running a GPU instance that is charged per second of processing time, what could you do to optimize the use of this resource? Running asynchronouse functions is one way to makes sure of this.

Asynchronous simply means not occuring at the same time

While loading the data, you may want to run a pre-processing function in the background for each data stream as it is being received. That way, the program would not have to wait for all of the data to have been loaded, before commencing pre-procesing. Hence, the data would not be pre-processed at the same time.

The code snippet above simulates the diverse cloud database endpoints mentioned earlier. The `fetch_data_from_cloud_db`function simulates fetching new data every 1 to 3 seconds. Then the `process_data` function processes the data from the queue in the background. It does this at random intervals between 0.1 to 0.5 seconds. It keeps running till the the `stop_event` is set and the queue is empty.

Finally, the main application sets up the queue, the stop event and creates the data fetching tasks. It simulates running the main application for 20 seconds. Once the application is done running, it then sets the stop_event, signalling the data processing task to stop. It cancels the fetch tasks and waits till all data in queue is fully processed before stopping the data processing task.

This method of handling tasks is also useful with micoservices that call serverless endpoints. During cold starts and request processing, you can set up your application to perform other tasks asynchronously, maximizing time and resource.

I hope you have learnt a thing or two here. If so, please like and share; I will also be happy to answer any questions directly or in the comment section. You can find the source code for the snippets here. You can adapt it for specific use cases.

We will talk about the tracemalloc module and monitoring tools like Grafana, AWS CloudWatch.

The code above simply loads an excel sheet into a pandas dataframe using the Pandas and Openpyxl libraries. It takes a snapshot of the memory before and after the dataframe load and logs out the top ten memory usage stats. The topmost stat from the logs is shown here:

INFO /Users/…/.venv/lib/python3.12/site-packages/pandas/io/excel/_openpyxl.py:61 memory_trace.py:21
6: size=3045 KiB (+3045 KiB), count=19987 (+19987), average=156 B ::                     

We see that the Openpyxl library currently makes use of the most memory (3045 Kilobytes), which is quite insignificant in the large scheme of things. However this can still be optimised. In a large code base, there is likely to be a process taking much greater memory.

Tracemalloc is a python module that helps to traceback where an object was allocated, get statistics on allocated memory blocks and compute the differences between snapshots to obtain memory use and detect memory leaks.

To track memory usage of applications in production, you can make use of tools like:

• AWS CloudWatch: For applications hosted on AWS, CloudWatch can be used to monitor momory usage and set up alarms for thresholds.

• Prometheus and Grafana: These tools used together can help pull and visualisze memory usage metrics over time.

Best Practices to Follow

For adhoc cases, you can run the “top” command on your terminal to see how much a running python program or any process is taking. If the memory keeps increasing, there is likely a memory leak somewhere. Best practices for managing memory usage includes:

• Code Reviews and Static Analysis: Perform regular code reviews using static analysis tools to identify memory management issues early.

• Garbage Collection Tuning: Configuring and tuning the garbage collector can help manage memory more efficiently.

• Testing: Implementing stress tests and load tests can help identify memory issues under high load conditions.

The aim is to bring to your consciousness these concepts and related tools, so you can refer to them later during your programming journey, prevent memory leaks and optimize memory usage in production.

🎯 - Dynamic Stability Control (DSC) System

These systems make use of sensors recording the steering wheel angle, acceleration, wheel speed and so on, to get a sense of the car’s stability and traction in real-time. They can automatically adjust the brake force or engine power to prevent skidding or spinning.

🎯 - Transmission and Gearbox

Formula 1 cars mainly use fully-automatic or semi-automatic gearboxes to enable them change gears rapidly taking instructions from the driver or a pre-programmed algorithm.

🎯 - Aerodynamic Control Systems

Active aerodynamic elements of the car like air ducts and adjustable wings can be controlled automatically using recordings of cornering forces, active speed and instructions from the driver themselves.

🎯 - Brake-by-Wire (BBW)

These electronically control the braking force distribution between the front and rear wheels to optimize braking performance and stability. This is automated and the driver by practice learns to hit the brakes only as much as need.

It may interest you that one of the main responsibilities of an MLOPs engineer is to automate things. Well why is this important? Are we just automating things for the sake of it? No, certainly not, especially when it does not bring real value. The key objective here is to reduce the amount of repetitive tasks and make things ultimately faster. As an MLOPs engineer you should think, would this script make this project faster? by how much? will this meet the service level objectives? Can I reduce the time it takes for this job to run by loading data a certain way? Can I make a CLI tool that makes creating a new project easier for Data Scientists?

Having these questions at the back of your mind will enable you figure areas that can be improved just by automating things. This mindset will help you go a long way as an MLOps Engineer and can be easily transferred to building intelligent systems in formula 1 cars.

F1 Section

When you think about sustainability what comes to mind? Carbon emissions?, recyclable materials, less waste, profitability? All of these are correct but how do they translate to F1? Some of these will be discussed here alongside how cost caps has contributed to it.

Flights!, lots of flights comes as a consequence of competing in different countries and these cost not just money but produces more carbon footprint. The Cost Cap introduced to F1 has well as ESG (Environment Social Government) scoring has pushed teams to aim at reducing the number of flights by transporting less dispensable workforce per race and finding environmentally friendly transport modes/fuels for their equipment (Cloud computing parts and Car parts).

Teams also do not have the luxury of building multiple car parts just to end up using one. The budget cap makes it such that teams will rather focus on making one front wing that works for example. Every dollar counts. Whilst these might “limit their freedom”, it helps create focus and responsible spending which translates to business profitability. More teams are becoming profitable because of this.

ML Section

Using the most affordable green fuel, less flights, less dispensable personnel per flight, predicting number flights for the year all sound like regression tasks, minimising some objective function. To approach this problem, I will start with the budget allocated to logistics and how that number can be minimised. Some will aim to make the most of that number. Asides that, another way to approach this problem is to maximise the ESG score as a regression task or and the ESG rating as a classification problem using a cascade design pattern.

To avoid overcomplicating/overfitting the problem, utilising an ensemble design pattern like bagging will suffice. This simply works by training a series of k similar models on k separate datasets and further aggregating the outputs of the k models to determine the best outcome. Since each of the initial models will not make the same mistakes on the test dataset hypothetically, averaging their results helps to cancel out each models’ specific errors. It is similar to having a board of directors who work together to suggest the best strategy only this time it is models. There is wisdom in the crowd. This helps to avoid overfitting the problem.

Summary

Budget caps help F1 teams become sustainable and therefore profitable.

Optimising team budget using a machine learning approach can be useful in helping teams become more sustainable and therefore more profitable.

The energy content of a fuel depends on its mass density.

Volumetric energy density typically measured in megajoules per liter (MJ/L) or Kilowatt-hours per liter (kWh/L). Where Ev​ is the volumetric energy density, E is the total energy content of the fuel, and V is the volume of the fuel.

Gravimetric energy density typically measured in megajoules per kg (MJ/kg) or kilowatt-hours per kilogram (kWh/kg). Where Eg​ is the gravimetric energy density, E is the total energy content of the fuel, and m is the mass of the fuel.

There are two types of fuel efficiency of a fuel mix: volumetric fuel efficiency and gravimetric fuel efficiency. The former, as the name implies measures the efficiency or energy density of a fuel as a measure of its volume whilst the later a measure in respect to its mass. Typically. the greater these values are , the more efficient a fuel is. You want sufficient fuel but as light as can be too. Remember in the last post how there it is iterated that there is no point optimising a car to only end up leading for a few laps, you need to win in the long run.

Optimizing for power with excess compromise for fuel efficiency is of no use.

You do not want to have excess fuel carried around to the end of a race, also you want to have optimized power as well as sufficient fuel to complete the race. So engineers calculate the amount of fuel they need to complete a full race. It will interest you to know, that although each race circuit has a different distance, the number of laps are adjusted to make each race roughly the same length. This often falls around 308 Km. Hence this makes it just a little easier to make the required fuel calculations. In recent years, Formula1 teams have adopted an hybrid power unit system (electric and fuel); however lets assume a simplified scenario without considering hybrid systems:

def calculate_fuel_required(distance, fuel_efficiency, energy_content):

    fuel_liters = distance / fuel_efficiency

    energy_required = distance * energy_content

    return fuel_liters, energy_required

fuel_efficiency = 5 # Fuel efficiency in km/L
energy_content = 35 # Energy content of fuel in MJ/L
distance_to_cover = 308 # Distance to be covered in Km

fuel_liters, energy_required = calculate_fuel_required(distance_to_cover, fuel_efficiency, energy_content)

print(f"Fuel required: {fuel_liters:.2f} liters")
print(f"Energy required: {energy_required:.2f} megajoules")

You can run the above code block in a python environment and replace the values as you wish. However, that is a simplified calculation of the liters of fuel and energy required for a race car to complete a race of a specific distance. Other factors including race conditions and engine come to play in a real scenario and edge computing is used to calculate these values quickly by running multiple simulations. We will discuss more on edge computing and its importance later.

Merry Christmas!

FIA - Fédération Internationale de l'Automobile (French: International Automobile Foundation),km -Kilometers.

Anyone who works in Formula 1 goes through a range of emotions each race year. So how easy is it to have the right state of mind to ensure proper team work, remain efficient whilst managing risks and conflicts. It takes loads of internal work to participate in this sport let alone remain competitive.

Pre-season, car designs are already being worked on. Design considerations cuts across reliability, safety and performance. What is the point in leading a couple laps only to end up gassing out towards the end and loosing places. Remember, it is a long game, the drivers train not only their driving skills, but their body, for increased endurance and focus. In a similar fashion, you want the cars to endure to the very end.

Light insight, I will go into more detail every post:

In Formula1, you have strict regulations just like every sport. Races are held in diverse locations, having diverse attributes and how that affects a team’s performance. Point to note:

Whilst it is difficult to design for all possible factors you may face, you should design to beat the odds.

You have got a bunch of regulations, a budget, specific drivers with different styles, and specific tracks to compete on. How do you bring these factors together to achieve your ultimate objective which often is to be on podiums. How do you achieve this whilst having team work, reduced cost and safety. Now this becomes a multi-objective optimisation problem. F1 teams require in-house Data Scientists and Machine Learning engineers, not to plot fancy graphs and build fancy algorithms, but identify the niche area , that sweet point that makes them in particular, competitive. Whilst charts and algorithms will aid in achieving these multi-objectives, the focus is often lost in the shadows, when engineers aim to prove who has the “best algorithm” or whatever that might mean. Team work is vital here, us not me, multi-objective not one objective, leading in the long run, not leading for a few laps. Mercedes AMG Petronas did not achieve 8 consecutive wins by luck.

Once this mindset and character is adopted across board, more importantly by the AI engineers who will be emerging to solve these data related problems, an F1 team can create consistent success. Work with your team to beat the odds!

As you might know, war in any sports, not just F1, is built outside of the activity; at least it starts there. Why? you might ask? “so not to look like a bunch of wankers!" at least that is what Guenther would say. But seriously, most of your time should be spent sharpening your swords, if you’ve got a war ahead. If not, well you end up loosing, and fast. Any wise competitor should know that.

In a sport like F1, each season, at least 20 races are held in different locations like Abu Dhabi in the middle east and now Las Vegas in the southwestern part of the U.S.A. You might think oh well, all that needs worrying about is the state of the cars and the drivers welfare. Yes, those are vital, infact, indispensable to being competitive in a race. However, there are multiple moving parts here and there that if not properly taken care of, might mean failure. A simple example is: If a competitor, lets say Ferrari, happen to have a better supply chain management and damage control, than a competitor, that alone can mean their cars arrive on time, they get enough time to test, and get sufficient time to fix anything that needs fixing. If the competitor fails in doing all of those, they are already a foot behind, especially when competing in a different climate from the preceding race. These things tend to happen often. So how do you fight this? you have to have the right guys everywhere! Nothing can be delayed, nothing should arrive earlier than needed or later. Now you have the to hire the right people on time, or a competitor grabs them; yes, do not think only drivers get scouted.

Another example, at the racing event this time, is when there is a penalty called against a team whose team principal believes was unjustified or gave an unfair advantage to a competitor or both. One of the FIA rules demands you go make your case to the authorities within 30 minutes of the race being over. Now if some staff from any side, gives you some assurance that it is okay to make your case within 45 minutes; for whatever reason; you might still get heard. And maybe the verdict goes in your favor. But be rest assured that the competitor(s) who gets impacted by that verdict will get wind of that seemingly harmless violation and they will definitely use that to get the verdict annulled. Do things within the specified time, simple. Things like this happen every season, if a team does not compete or war wisely, that might mean loosing a podium and likely a couple million bucks! no team wants that, especially in a sport that is very expensive to run.

Time is of the essence on and off the track, in and out of season, in and out the paddock.

Out of a total of 20 races so far this year, Max Verstappen, Red Bull Driver, has won 17 of those, 17! If you analyse that a little further, there are a total of 20 drivers competing in F1, and where each driver had a chance of winning once, Max has won 17 times.

But if you watched Max and the Red Bull team closely, they were not always this successful. So what changed?

Consistent success on the track takes a while for a combination of new factors, even though very efficient, to become familiar with. This goes both for the drivers and the cars engineered for them.

Ultimately, performance is mostly due to efficiency than strategy

It is clear Max has a great car engineered and is as good as any driver and most likely better to have achieved this streak. But it took time for him to achieve this fit; He had to gain mastery of his car, his opponents and the tracks where they come to battle each year. Ultimately his speed and efficiency of other engineering factors gave him an edge over teams that probably had better pitstop Engineers with shorter pitstop times or had better racing strategies. His efficiency crossed the threshold for him to outshine others.

The same goes for the AI space, where python outshines other languages due to its ease of use and beloved community. Whilst this was good for the ground work days, there comes a time when unfamiliarity has to be dealt with for advancement. Languages like Rust, which is strongly statically typed is unfamiliar to most AI Engineers though it outperforms rust in speed and efficiency (It can run computations faster on less expensive compute instances). But just as Max was in his stage of getting familiar with the factors thrown at him, languages like Rust 🦀 , are just getting started and will likely outperform Python in production adoption. Since it is a low-level language, it will definitely play a useful role in building embedded systems in F1 automobiles and forecast systems, as what plays the most important role in this space is speed! Go fast or Go home. Every team should want every system to be as fast as is safe to operate. From their supply chain to their technical systems to their driver on the wheels.

This clearly is the first equation that you need to keep in mind. It is the basis of all the other equations. It is also the basis of Newton's second law of motion. In designing your ML model to predict car acceleration, you need to keep this in mind.

🏎️ - F = mv^2/r (Centripetal force = mass * velocity^2 / radius of turn)

This is the equation for centripetal force. It is the force that keeps the car in a circular path. It is the basis of the equation for cornering speed. Each F1 car has a cornering speed that it can take a corner at. This is the speed at which the centripetal force is equal to the force of friction. Any faster and the car will skid off the track. Any slower and the car will be able to take the corner but will be slower than the competition. Your model can predict the speed of a complete lap by taking into account the cornering speed of the car.

🏎️ - F = 1/2 * Cd * A * rho * v^2 (Drag force = 1/2 * drag coefficient * frontal area * air density * velocity^2)

This is the equation for drag force. It is the force that opposes the motion of the car. It is the basis of the equation for top speed. C is the drag coefficient, A is the frontal area of the car, rho is the air density and v is the velocity of the car.

Keep in mind, there is a threshold, Aerodynamics start to have a more noticeable affect on a vehicle at around 50 mph.

Your model can predict the drag force the car may experience by taking into account the expected top speed. Drag force rises with the square of the speed, so doubling the speed requires four times the power to overcome air resistance. This is why F1 cars have such high power outputs.

FINAL NOTES

The relationship between power and force is given by the equation P = F * v (Power = Force * velocity). Hence the more mass it has, the more power it could produce. But remember, there is always a tradeoff whether obvious or not, and there are always thresholds to consider too. Always aim to find these making use of your ML model, making the right analysis with the right features.

🏎️ - Sustainable innovation has been a popular topic in many sectors for the past few years.

Read more