Data Is Everywhere — And Humans Can’t Track It All

In every organization, data is scattered:

• Goals, plans, projects

• Different tools, multiple planning tools

• Tools deployments over time. Locked in data.

• Design decisions and validations

• Lessons learned from previous projects

• Notes from cross-functional teams

Traditionally, humans must dig through each source to reconnect with knowledge. But what if AI could do that for you, continuously, accurately, and without extra effort?

No need to build a Zettelkasten. No need to migrate to Obsidian. No need to redesign your entire system.
If your information already lives in docs, Notion, databases, or project tools — that’s enough.

🤖 AI as Your Continuous Knowledge Assistant

AI can become the entity that bridges scattered data and decision-making. It:

• Explores your entire knowledge base

• Connects ideas across time

• Notices when plans drift from goals

• Reminds you of forgotten assumptions

• Highlights hidden dependencies

• Surfaces opportunities you might have missed

Real-world examples in automotive:

1. Design Validation & Lessons Learned
   AI scans historical design decisions, recalls past failures or recalls, and flags potential issues in new designs before simulation or production.

2. Supplier & Component Risk Assessment
   AI continuously monitors supplier quality reports, audit notes, and field data, alerting engineers when a supplier or part may impact safety or performance.

3. Project Planning & Resource Optimization
   AI analyzes ongoing projects, past project timelines, and team availability to suggest better sequencing, highlight potential bottlenecks, and surface overlapping efforts.

Example outputs:

• “This new component choice conflicts with a past design decision — consider alternatives.”

• “Two teams are solving overlapping problems; resources could be better aligned.”

• “This feature was delayed in the past due to supplier issues. Mitigation recommended.”

Subscribe now

🧠 Humans Provide the Compass

AI surfaces insights, but humans still set direction and define meaning:

• Choosing trade-offs

• Making judgment calls

• Creating new ideas

• Guiding the team

• Deciding what actually matters

AI expands your field of view. Humans provide the compass.

🔁 A Leadership-Oriented Way of Working

1. Plan, write, and document as usual

2. AI digests and surfaces insights from your data

3. You gain clarity, context, and foresight

4. Make the final decision — faster, better, more confident

✨ The Real Advantage

Leaders have tried to optimize knowledge flow for decades. What matters is acting on information at the right time. AI’s strength is continuous data churning, turning raw knowledge into actionable insights.

AI can be your:

• Leverage

• Thinking multiplier

• Time-saving engine

Leaders: are you turning knowledge into action — or still relying on memory and reports?

The gap is where AI wins. Where does your organization stand?

Leave a comment

TL;DR

• 📵 My phone shows zero SMS notifications

• 🤖 All SMS are processed by n8n + local AI (Qwen)

• 📬 Only important messages (like real OTPs) send via telegram notification

• 🛡️ Spam, promos, and scam messages are silently filtered

• 👴 Real benefit when used as guardian covering families that can generate alerts for fraudulent financial transactions

• 🏠 Runs fully locally, no cloud AI, full control

The Problem: SMS Is a Security Nightmare

My phone receives:

• Bank OTPs

• Delivery alerts

• Login codes

• Promotions

• Obvious scams

• And increasingly… very convincing phishing messages

Important messages get buried. Worse, senior citizens in the family are especially vulnerable to:

“Your account will be blocked”
“Click here to verify KYC”
“Urgent: call this number”

This is not just annoying any more. It’s a security problem.

The Idea: Build an AI Firewall for SMS

Instead of trying to mentally filter messages, I decided:

Let software do it. Automatically. Reliably.

So I built this:

• 📱 Phone receives SMS

• ⚙️ Tasker app sends SMS to n8n Webhook

• 🤖 n8n sends it to local AI (Qwen)

• 🧠 AI classifies the message:

  • OTP?

  • Bank alert?

  • Important?

  • Spam?

  • Scam?

• 🗃️ Message is logged in NocoDB (future data analysis on patterns)

• 🚦 Rules decide what happens next

• 📬 Only important messages go to Telegram

And then:

📵 I turned OFF all SMS notifications on the phone.

The Result: Telegram Is Now My Smart Inbox

• ✅ No spam

• ✅ No promos

• ✅ No fake messages

• ✅ Only real, relevant alerts

• ✅ Clean, quiet phone

• ✅ Full audit trail in database

Telegram becomes my filtered, intelligent SMS inbox.

Why Local AI (Qwen)?

• 🔒 No privacy leakage

• ⚡ Fast

• 🏠 Runs on my own machine (proxmox/ollama host in this case)

• 💸 Zero per-message cost

• 🧠 Fully customizable prompts and rules

This is not a “toy chatbot” use case. This is real automation.

The Most Powerful Use Case: OTP Protection

This is where it gets serious.

Instead of:

“Any message with numbers = OTP”

I can do:

• Check bank name

• Check service name

• Check context

• Check time window

• Check expected flow

Only then:

🚨 Send alert to Telegram

Everything else is ignored or logged silently.

The Bigger Plan: Protecting Family (Especially Seniors)

Next step:

• Install this on family phones

• Especially for senior citizens

• All SMS go through AI filter

• Only safe, verified, important messages reach them

• Suspicious messages:

  • Auto-blocked

  • Or sent to me for review

This becomes a fraud firewall for humans.

Why This Matters

Scams are no longer stupid.

They look real.
They use real names.
They mimic real banks.

But:

AI + automation can outscale scammers.

The Philosophy

Don’t fight spam.
Architect it out of your life.

Final Thoughts

This is one of those systems that, once built, you forget it exists.

• Your phone is silent.

• Your mind is calm.

• Important things still reach you.

• Everything else disappears.

That’s the best kind of automation. 😌

In the high-speed world of automotive software development, where reliability is no longer an option but a matter of life and death, each design choice is of enormous consequence. The employment of global variables is a particularly sly technique, when writing software that meets functional safety standards such as ISO 26262.

Though they may seem to provide convenience – instant access to information from anywhere within the codebase – global variables are actually sneaky saboteurs. They present a myriad of problems that erode maintainability, predictability, and, in the long run, the safety of your automotive systems. Let's unpack why global variables represent a basic anti-pattern in safety-critical automotive software:

The Developer Impact: A Maintenance Labyrinth

Picture a huge, intricate automotive embedded system with thousands of lines of code. Picture attempting to trace out every location where a global variable could be read from or, more importantly, written.

Spaghetti Data Flow:

Global variables introduce latent dependencies. A modification of a global in a corner of the code will have unintended effects in an entirely unrelated module. This spaghetti data makes it virtually impossible to know the system's real behavior without tracing every access.

Decreased Readability:

For a new programmer coming in on the project, learning the system state is an enormous undertaking. They can't just glance at a function signature to learn its inputs and outputs; they have to deduce its interaction with perhaps dozens of global variables.

Refactoring Nightmares:

Modifying or removing a global variable, even if it seems unused, requires an exhaustive analysis of the entire codebase to ensure no hidden dependencies are broken. This makes refactoring risky and time-consuming, often leading developers to avoid necessary architectural improvements.

Unpredictable Memory & Concurrency Issues (Beyond the Stack)

Although global variables do not live on the stack (they live in static memory), they pose critical memory and concurrency issues that are just as, if not more, hazardous in a real-time, multi-threaded automotive environment.

Race Conditions Galore:

Where there is more than one task, thread, or interrupt service routine (ISR) – and this is a typical situation in automotive ECUs

global variables are the first to be targeted by race conditions

If two or more paths of concurrent execution try to change a global variable without any appropriate synchronization controls (such as mutexes or semaphores), the resultant value of the variable is non-deterministic and relies on the timing of execution. This is a well-known root of hard-to-reproduce bugs.

Memory Footprint & Lifetime:

Global variables hold memory throughout the application's lifetime, whether they are in use or not. Although this may appear insignificant, in resource-limited ECUs, poorly optimized memory usage can cause other problems or constrain future features. More significantly, their eternal presence means that their state is preserved across execution cycles, with the risk of propagating erroneous values from previous operations.

On average, most of the ECU have more than 80% of RAM consumption, its very hard to eliminate global variables.

Cache Coherency Issues:

In multi-core processors, global variables shared among multiple cores can cause cache coherency issues, where multiple cores may retain stale versions of the variable within their local caches, creating yet another layer of complexity and potential for misbehavior.

The Catastrophic Effect on Data Flow

Data flow addresses how data is transferred, converted, and utilized across the software system. Global variables devastate this important factor:

Hidden Inputs and Outputs:

Functions manipulating global variables have "hidden inputs" and "hidden outputs." 

A function's interface may imply that it has no arguments or no return value, but it might be reading from or writing to a global variable, effectively changing its behavior or system state. This renders function contracts transparent.

Inability to Trace Data Origin:

When a bug is created due to a global variable containing an improper value, it is extremely hard to trace back the source of that corruption. Without explicit parameters, there is no direct "chain of custody" for the data. Where does this value originate? Which one of the numerous functions capable of writing to this global actually set it improperly?

Massive Side Effects:

All functions that change a global variable produce a side effect on the overall system state. This violates modularity and prevents reasoning about the behavior of a function in a vacuum, since its effect permeates far beyond its immediate return value or output parameters.

No Single "Owner" of Data:

Without encapsulation, global data does not have a single responsible owner. Anywhere in the code can change it, causing a diffusion of responsibility and turning debugging or updating data structures into a minefield.

The Dangers of the Impact on Control Flow

Control flow governs the sequence in which instructions are followed and decisions are taken within the software. Global variables add perilous unpredictability to control flow:

Hidden State-Dependent Decisions:

Decision points (e.g., `if` statements, `switch` cases) usually rely on the value of variables. If such variables are globals, their values might be changed by any other section of the system at any time. This implies the actual run-time path (control flow) might get changed in an unpredictable manner depending upon the hidden state of global variables, and it is very hard to test all the possible execution paths.

Execution Path Non-Determinism:

As soon as more than one task or ISR have the ability to alter global variables, the exact timing of these alterations matters. The sequence in which these simultaneous operations occur may decide which branch of an `if` statement is executed or which `case` in a `switch` is entered. This results in non-deterministic control flow, where identical inputs will produce different outputs as a function of infinitesimal timing differences – the signature of an untestable and unsafe system.

Complex Cyclomatic Complexity:

Although not technically raising the raw number of decision points, implicit dependencies created through globals raise the effective complexity of comprehending and checking control paths significantly. Any function that accesses a global inherently relies on any function that modifies it, thus building an intertwined web of possible execution paths.

The Exorbitant Cost of Diagnostics

When a system fails as a result of an incorrect state of a global variable, the debugging process is a nightmare.

We Can't Trace Backwards:

Compared to local variables propagated via a call stack, there isn't a traceable chain of custody for a global variable value. You cannot simply look at the call stack and determine from where an incorrect value is coming.

Debugging Hell:

Pinpointing the exact line of code that corrupted a global variable often requires setting breakpoints everywhere it's accessed, meticulous logging, or advanced (and costly) hardware debugging tools. This process is incredibly time-consuming, expensive, and often delays critical project milestones.

Certification Obstacles:

Traceability and debuggability are most important for ISO 26262. Diagnosing systems that are difficult to diagnose extend the verification and validation phases, making development more expensive and potentially holding up certification.

Bug Leakage and Propagation

A small bug that corrupts a global variable in one location of the software can "leak" or propagate its faulty state throughout the whole system.

Far-Reaching Consequences:

A malfunctioning sensor processing function that writes to a global vehicle_speed variable in an erroneous way could, for example, cause mistaken braking decisions, inappropriate cruise control operation, and misleading dashboard display – all apparently disparate functionalities affected by one tainted global.

Hard to Localize Repairs:

If the bug appears in a remote location of the code from where the global was damaged, it is a "whack-a-mole" to fix it. A repair in one place may unexpectedly create problems somewhere else because the interaction between the global and the rest of the system wasn't well understood.

This renders it difficult to obtain "freedom from interference," one of the most important ISO 26262 guidelines.

Beyond the Basics: Functional Safety Compliance

The utilization of global variables is in direct contradiction to some of the basic principles of ISO 26262:

Modularity & Independence:

Strong isolation of safety functions is usually needed. Global variables disturb this isolation by introducing implicit coupling among modules, which is difficult to prove their independence.

Interference Freedom:

It becomes extremely difficult to prove that the execution or use of data of one software component does not negatively impact another when globals are present, particularly in relation to shared global state.

Verification & Validation:

It is very challenging to unit test functions that depend on globals, with convoluted test arrangements or heavy mocking often necessary to mimic the external state. Integration testing becomes more cumbersome and less efficient at identifying root causes since the interactions are opaque.

Traceability:

Tracing back requirements to design elements and subsequently to code, particularly data flow and control flow, becomes unclear and excessively complicated with extensive global variable usage.

How Tools Can Assist (But Not Fix)

Although removing global variables is the optimum objective, tools can provide some detection and mitigation:

Static Analysis: These tools examine source code without running it.

Uninitialized Global Detection: Detect global variables that are declared but not initialized prior to their usage.

Reports for Global Variable Usage: Plot where each global variable is read and/or written. This is a visual indicator for following implicit data flow.

Enforcement of Coding Standard (e.g., MISRA C):

MISRA C, popular in the automotive sector, has certain rules (e.g., Rule 8.7, 9.3, 13.5, 17.8) that limit or discourage some applications of global variables, particularly those that are not declared `static` at file scope, and those read by ISRs or multiple tasks. Static analysis tools can automatically report violations, imposing improved data encapsulation.

Possible Race Condition Detection:

Static analyzers with advanced capabilities can analyze control flow and data flow to identify possible race conditions on global variables, even if absence cannot be proven.

Tools : Polyspace, PC-Lint, SonarQube, Helix QAC.

Dynamic Analysis: Such tools observe software behavior at runtime.

Runtime Error Detection: Allows for detection of real race conditions, memory corruption, and access to uninitialized global variables at testing time. This validates bugs found with static analysis or reveals new ones that only appear at runtime as a result of particular control flow paths.

Code Coverage: Ensures proper testing of all execution paths, including those that involve global variable changes, which is important for validating complex control flows.

Memory Profiling: Pinpoint memory usage patterns and potential leaks associated with global variables (even less frequent with static memory, but can reflect unforeseen persistent state).

Methods: Special hardware debuggers with tracing, special runtime error detection support libraries, logic analyzers.

The Way Forward: Encapsulation and Clean Interfaces

The way out of the global variable problem is to accept encapsulation and clean interfaces.

Pass by Parameter:

Pass data between functions explicitly as parameters. This makes data flow transparent, testable, and deterministic, making function contracts and control flow dependencies clear.

File-Scoped Static Variables:

For information actually unique to a single compilation unit, static file-scope variables (`static int my_var;` in a `.c` file) provide a safer replacement for global variables. They limit visibility, facilitating easier reasoning about their access and data flow localized to regions. But even these need to be carefully handled in order to avoid race conditions in multithreaded systems.

Principles of Object Orientation:

Even in C, using object-oriented thought (structs with corresponding functions) will encapsulate data and the functions that alter it, instead of making raw data available everywhere. This keeps related data and code together that acts upon it, resulting in clean data flow and more predictable code.

Design Patterns:

Use design patterns such as the "Singleton" pattern (judiciously and only when absolutely necessary, since they can reproduce global issues if used too extensively) or "Dependency Injection" to deal with shared resources in a controlled way, with explicit dependencies instead of implicit ones.

When it comes to automotive functional safety, taking shortcuts with global variables is a risky bet. Though they are superficially convenient,

Global variable create systemic hazards that make maintenance worse, complicate data and control flow, cause system behavior to be unpredictable, drive diagnostic costs higher, and make conforming to rigid safety standards such as ISO 26262 far more difficult.

Today's automotive software requires strong, predictable, and verifiable code. Through careful avoidance of global variables and embracing of principled design with well-defined interfaces and encapsulation, developers can create safer, more reliable, and ultimately more maintainable systems – so the cars of the future are not only smart, but flawlessly safe.

Share Parag Barangale

My setup is having Home assistant behind a NAT’ed IP. It means Cloudflare tunnel is essential to accessing my services.

Recently installed Eclipse Mosquitto broker through home assistant add-ons.

Initial Attempts

HA add-on config allows four ports for access as shown below.

In my first attempt, I forwarded the port 2892 for normal MQTT, and tried to access it. That does not work, checked the add-on documentation. It required to -

Created account, still not able to access. What could be wrong. One thought was since this is diff that regular port forwarding there might be something additional required or Cloudflare may not support it.

What is the issue

Cloudflare tunnel can fwd the request on the port, but MQTT needs port open when accessing

See the setting window from MQTT test tool. It wants to know the protocol, host and port. From Cloudflare tunnel we hide the Port and only the host and protocol is known.

Attempts to tunnel raw TCP MQTT traffic (e.g., tcp://192.168.1.150:1883) often fail, as Cloudflare's infrastructure does not natively support generic TCP proxying for MQTT

There is one alternate, which you can be aware of is - Cloudflare's own Pub/Sub service supports MQTT v5.0

What could be the solution

We have now established two facts, 1. create account and 2. TCP is not supported. If you look at ports used by broker. You could see it supports MQTT over web sockets. This is great as web socket will be the protocol that is supported by Cloudflare as well.

The way to do is;

Setup Cloudflare tunnel to fwd HTTP to web socket port of broker

Listed 4 steps;

1. Setup URL to point to

2. Select HTTP Type

3. IP address of MQTT broker - this is my localhost machine where CF tunnel is installed.

4. Port address of Web socket (MQTT over Web socket )

MQTT broker setup to use Web socket - SSL. (Cloudflare provides it by default)

MQTT Desktop Client

In order to test the MQTT Broker and Client communication, use a local app for testing. Most browser now do not allow to use websockets connections. Shown below are the settings for MQTT explorer client settings.

Protocol is WS, host address as defined in Cloudflare tunnel, port is empty. Username and password as defined in home assistant.

MQTT Android Client

Great till now, but we need mobile to work. I tried some apps here. One problem I encountered, port number is absolutely mandating. Which portcan support this ?

There is a solution, use the SSL port and Web socket with SSL as shown below. Setting for app IoT MQTT Panel. Port 443 is the standard port for HTTPS, the secure version of HTTP.

Autosar E2E Protocol Specification defines mechanisms to detect faults related to communication, covering lower communication layers and hardware. This help to standardize safety mechanism for faults.

The specification provides multiple profiles that could be used. Profiles would be based on your system (e.g. based on Safety Concept). Between profiles Counter, DataId and CRC checksum are common. Some profiles have added or timeout detections. One subtle difference is, although the fields are the same, the field size varies.

Field Size Impact

To understand the impact of field size, let understand what CRC is. Cyclic Redundancy Check (CRC) is an error-detecting code used to detect accidental changes to raw data during transmission or storage.

To detect an error in a message, a CRC value is provided along with the message. The receiver shall calculate the CRC again and compare the CRC received. The critical factor is the value of CRC shall be always unique for all possible combinations of the message. If you consider the CRC is of 8bit and message is of 4 bytes long, you have very high probability that CRC no will not repeat for combinations. Extending this further, if 8-Bit CRC is used to calculate a message of 1000 bytes, you now have very high probability the CRC value will get repeated, low probability and low error detection.

You shall select sufficient length of CRC to ensure high detection capability, hence we choose the field size appropriately.

Counters

Counter field in profiles provide a ways to detect - Repetition, Ok and Error states. Once the counter is filled, its rollovers. Different profiles give you the option to select the size of counter. Example, in profile 1 the counter size is 0xF whereas profile 4m will roll over at 0xFFFF.

To understand how rollover effects, consider some CAN message fault scenarios.

• Signal lost - Once

  • Sender and Receiver, both at counter 4

  • Receiver missed the one message due to some issue on the bus

    Receiver is expecting msg with counter value as 5.

  • Till value 5, all messages would be categorized as Error for receiver.

    Receiver will be in Ok state once rollover happens and next message with 5 value is received.

  • If we assume the cyclic message is with 10mSec. Resync will happen after 0xF*10msec.

  • For profile 4m this will be 0xFFFF * 10mSec.

The above example considers only 1 scenario of CAN fault and a functional requirement to wait till valid counter value is received.

Expand this further to consider all the CAN fault scenarios: No first message, random drops, multiple disconnects, total disconnect.

Summary

E2E provides a way to detect fault, further analysis in your system is required to ensure the system can always recover on its own when the condition is cleared. To build a robust system you will need to map all the communication bus faults with recovery strategies like, resync with each message, resync up to certain count (also defined in some profiles) and further…

In case of functional safety, you need to additionally consider from FTTI perspective. E.g. if recovery is happening at rollover, does it comply with FTTI timing. If not change recovery strategy or enter directly into safe state (system very sensitive) or exit after stabilization/debounce period.

TLDR;

Choose E2E profile based on data/error detection requirement.

Analyze all the faults, and define exit criteria

In transition, consider the impact on modules when faults are detection. What should be their state and/or reaction.

In the world of embedded systems, reliability is paramount. One of the critical tools engineers use to ensure system stability is the watchdog timer (WDT). While setting up a watchdog timer may seem straightforward, calculating the correct watchdog period is far more complex than it appears. This blog will cover why the watchdog is required, the difficulties in calculating the right period, how testing impacts the timer, key considerations, and what to do when the watchdog triggers—both in development and manufacturing stages.

1. Why Is a Watchdog Timer Required?

The watchdog timer serves as a safeguard against system failures or software malfunctions. In an embedded system, there are instances where software may crash, enter infinite loops, or encounter deadlocks. Without a mechanism to recover, such failures could make the system unresponsive, leading to costly consequences, especially in safety-critical applications like automotive, medical devices, and industrial automation.

The watchdog timer ensures that if the system stops responding, it will automatically reset itself to avoid further issues. It essentially functions as a reset button, constantly monitoring the health of the system and expecting a regular "kick" (a signal that the system is still functioning). If the kick doesn’t happen within a set period, the watchdog assumes the system has malfunctioned and triggers a reset.

Subscribe now

2. Why Is It Difficult to Calculate the Watchdog Period?

Calculating the correct watchdog period is a balancing act that comes with challenges. If the period is too short, you risk premature resets (false positives) when the system may simply be running a longer task. On the other hand, setting it too long may delay detection of an actual system failure, reducing its effectiveness. The difficulty lies in accounting for real-world factors that affect system timing:

• Task Execution Variability: In systems with multiple processes, some tasks may take longer to execute than others. You need to ensure that the watchdog period accommodates the longest task without triggering a false reset.

• Interruptions: Interrupts or higher-priority tasks can delay execution of the watchdog-resetting function. Ensuring the timer is long enough to account for such delays can be tricky.

• Dynamic System Behavior: In systems where the workload can vary significantly, predicting how much time is needed to reset the watchdog can be challenging.

3. Why Does Testing Impact the Calculated Value?

Testing plays a crucial role in refining the watchdog period, as it helps to identify the system's worst-case execution scenarios. During development, engineers may estimate how long tasks will take based on theoretical or average values. However, under real-world conditions, testing may reveal unexpected delays, bottlenecks, or unaccounted-for system behaviors that alter the expected task durations.

• Stress Testing: When a system is under heavy load, tasks may take longer to execute due to resource contention. This can impact how frequently the watchdog can be kicked.

• Real-Time Performance: Some tasks might execute slower in a deployed environment compared to a controlled development environment due to hardware limitations or environmental factors like power fluctuations. Testing across different conditions is essential to adjust the watchdog period accordingly.

4. What Should Be Considered in Watchdog Calculation?

Several factors need to be considered when calculating the watchdog period to ensure it is set correctly:

• Task Cycle Times: Understand the execution time of each critical task, particularly the longest task. The watchdog should not reset the system prematurely if a valid task is still running.

• System Latency: Consider delays from interrupts and task scheduling, especially in real-time operating systems (RTOS). These can vary based on priority levels and timing jitter.

• Safety Margin: Always include a buffer or safety margin on top of your worst-case execution time to account for unexpected delays.

• Clock Frequency: Take into account the clock frequency of the watchdog timer itself and how it interacts with your system's clock, as this will affect your calculation for timeout periods.

• Power Consumption: In low-power or battery-operated systems, the watchdog timer might operate slower, so these factors should be reflected in your calculation.

  WDG period is calculated theoretically based on your task executions. Setting this value validates both your design and real-time performance.

  If they do not work, evaluate where is system is deviating. Again, do not just change the WDG period

Share

5. What to Do When the Watchdog Triggers in the Development Cycle?

When the watchdog timer triggers during the development phase, it is important to treat it as a signal that something in the system isn’t behaving as expected. Here's what you should do:

• Identify the Cause: Use debugging tools to figure out why the watchdog wasn’t kicked in time. Did a task run longer than expected? Was there an unhandled exception or deadlock? Trace back the issue to see where the code or system behavior broke down.

• Optimize Task Execution: If certain tasks are causing delays, consider optimizing the code or breaking up tasks into smaller, quicker cycles to ensure the watchdog is regularly kicked.

• Implement Graceful Recovery: If the watchdog reset occurs, ensure the system can recover smoothly without data loss or critical failure. Logging the watchdog reset event can be useful for postmortem analysis.

• Adjust the Watchdog Period: If the task cycles are indeed running longer than initially calculated, consider extending the watchdog period. Be careful, though—this should be done only after verifying that the delay is legitimate and not due to a deeper issue in the code or system design.

6. What to Do in Manufacturing?

Once your product is ready for manufacturing, the behavior of the watchdog timer can be more challenging to control since the system will be deployed in real-world conditions. Here’s what to consider:

• Field Testing: Before mass production, field-test your system under various conditions (temperature, power supply, interference, etc.) to validate the watchdog period.

• Default Watchdog Settings: Set conservative default values for the watchdog timer in production. Ensure these values have been tested to work reliably under normal operating conditions.

• Bootloader - Application code: If you intend to use bootloader, ensure when an application is switched, the watchdog is reinitialized or setting are verified. As when large amount of code flashing is done, clearing watchdog is not practical and usually watchdog is disabled or keep at max period.

• In-Field Debugging: Implement logging mechanisms that can store information before a watchdog reset happens. This will allow you to retrieve useful data when troubleshooting in the field.

• OTA Updates (Over-the-Air): If possible, implement OTA update mechanisms so that watchdog parameters can be adjusted remotely if issues arise post-deployment.

• Graceful Handling of Resets: Ensure that when the watchdog triggers a reset in the field, the system can restart without major disruptions, data loss, or user impact. Smooth system recovery is essential for maintaining customer satisfaction.

Conclusion

The watchdog timer is a critical safety component in any embedded system, but getting the timing right is no easy task. A poorly calculated watchdog period can either render the system unresponsive to failures or cause unnecessary resets that disrupt normal operations. Understanding your system’s behavior, testing under real-world conditions, and considering factors like task cycle time, interrupts, and safety margins are key to calculating an optimal watchdog period. Both during the development and manufacturing phases, keeping a vigilant eye on how the watchdog performs will ensure the long-term reliability of your system.

Leave a comment

We usually see adding compliance to increase the cost, that’s a fact. Equally, there is also a gain to be specific - financial gain in compliance. This article aims to show the benefits of compliance.

In some cases, non-compliance is mandatory, such as regulations. In this case it’s not optional, we will skip these mandatory cases. We will be focussing on compliance to internal process defined by an organisation.

Before delving into the economic analysis, it's imperative to establish a clear understanding of what compliance and non-compliance entail. Compliance encompasses a broad spectrum of activities aimed at ensuring that businesses operate within the bounds of frameworks. Non-compliance, on the other hand, refers to the failure to adhere to these requirements. This failure can result from oversight, negligence, intentional misconduct, or a lack of awareness of existing process.

Let’s take a case where we are trying to develop a hardware development of a product. Consider only one task - develop the PCB.

Example - PCB Layout

In order to fulfil this task, the designer shall bare minimum consider;

• Customer/product requirements.

• Physical constraints.

• Product environmental considerations

• Lessons learnt (previous products)

• Field data monitoring

• Regulatory requirements

We have to assume for each product development this shall be done. Else we fail at some sub-task, eventually the product fails.

The product must comply to requirements, environment and regulations. If not, we have a liability of failed product and the financial consequences coming out of it.

Subscribe now

Where is compliance

Compliance comes when you define a process to each of this task. This is to ensure when the product gets developed, all aspects will get covered. We will take a couple of examples to understand how it all expands and interacts.

I. Product environmental considerations

The process shall define what the development and test inputs to be considered. E.g. while developing an automotive product -

1. Automotive temp range shall be considered.

2. The components all shall qualify for Automotive grade.

3. Apply the compliance as per market. For EU -UN ECE R10, for US its CISPR.

II. Field Data Monitoring

This is one of the most crucial aspects. If you are not in control, this single thing can turn your organisation into loss making. For each new product development, a bath tub curve is usually referred. New launches start with high failures defined as Infant Mortality and after some time failures are reduced and remain static. And finally Wear out failures occur.

Wiki - Bathtub curve

As an organisation, you need to monitor the field returns. Quantify what caused the failure - was it the component failure, manufacturing process, supplier quality, design issue. The process shall define the steps to recover from these failures. The bathtub curve shows how it should be, but if you do not take action on your field returns, then you would remain in high failures always. This wall cost so much as part of warranty and other issues. Industry practice is to deploy 8D process for this.

Wiki - Eight disciplines problem solving

Process Compliance

A checklist is the easiest way to ensure compliance. Develop a checklist for PCB designer. The checklist will ensure if he has captured all the requirements. E.g. If regulatory requirements are not available, then you could reach to the customer and define those. Or if the temp range is defined but does not match automotive range, that’s another red flag.

Similarly, on the field data monitoring, a dedicated person can capture field data and generate the PPM for the organisation. He could also drive the issue through 8D so that it never gets repeated.

Compliance ensures the same issue will not get repeated ever.

When the issue does not repeat, the efficiency is improved and so are the profit margins. In current world scenario, the margins are under heavy pressure. It’s not an utmost priority to ensure the process is defined properly and runs smoothly.

Compliance fosters a culture of accountability, transparency, and integrity within organisations, which enhances trust among stakeholders and contributes to long-term business resilience. Moreover, compliance is increasingly recognized as a strategic differentiator in today's competitive landscape.

Organisations that prioritize compliance demonstrate their commitment to ethical business practices, sustainability, and corporate social responsibility, thereby attracting customers, investors, and top talent.

Embracing Compliance as an Investment

In conclusion, the evidence overwhelmingly supports the notion that compliance is not only cheaper but also essential for sustainable business success. While compliance entails upfront investments, the costs of non-compliance far outweigh these expenses, both in financial and reputational terms.

By investing in compliance, organisations not only mitigate risks but also unlock opportunities for growth, innovation, and competitive advantage. Compliance is not merely a regulatory obligation; it is an investment in the integrity, resilience, and longevity of businesses in an ever-evolving regulatory landscape.

Therefore, rather than viewing compliance as a burden, organisations should embrace it as a strategic imperative and a cornerstone of responsible business conduct. In doing so, they not only protect their bottom line but also uphold the trust and confidence of their stakeholders in an increasingly complex and interconnected world.

Thanks for reading SME’s Substack! Subscribe for free to receive new posts and support my work.

Why Estimate?

Estimation is required to do anything, it is the basis of gathering all the required resources. The task estimations will help you to plan the project.

In one case where you plan without estimate, it uses something called guesstimate. It means guess the estimate.

Contributing Factors

Estimation dictionary meaning is ‘opinion or judgement’. The nature of the activity is your opinion. Getting estimation right is always tricky and challenging due to so many variables.

E.g. We consider a resource with the same exp to have the same productivity, but these are two different persons - the productivity will be always different. How will be estimation absorb that variation.

The base for estimating needs to be built upon. Each step of your development has potential to derail the estimations. Be it the developers, availability of tools/stuff to customer input delays. Let’s take one example to understand estimation gone wrong.

Thing that contribute to the estimation are;

• Experienced estimator

• Previous execution timeline (the actual delayed)

• Usage of resources

• Dependencies

• Feedback delays

• Reuse

Experienced estimator

If you have experience as project manager in the same organization and on a similar type of project. Then the estimations are likely to be more accurate since you know the pain that happened when you executed the project which estimated less than required efforts.

Similarly, for architects, leads, developers - the previous experience counts

Previous execution timeline (the actual delayed)

An easier approach when we lack a team of experience resources. Take a sample of previously executed projects. It is very critical to look at lessons learned (good & bad) section and change request.

Lessons learn show where the time could be saved for future projects.

CR Change request - Whenever CR are accepted, they kind of reset the project timeline. While sampling, you could look at the initial plan and the final plan, and you might wonder the project took twice the time, CR might have contributed to that.

So using CR data you can normalize the inflated timeline and then process the data for your estimation.

Usage of resources

This is a bit complex due to the nature of resources involved. I will list a few here, this is very specific to your project.

• Skilled team

• availability of target/hardware

• Availability of test platform

• customer acceptance testing

• 3rd party software/libraries

Based on the availability of the resource, you would be able to complete the task. Hence, the estimation for the task will vary accordingly.

Feedbacks

If you have milestone release, the feedback shall be received by a particular time to incorporate the changes. The more delay in feedback, the more last minute efforts required to squeeze the change. The customer shall be notified about feedback window, or it would be considered as Change Request.

Reuse

Almost all organization love to reuse to save cost. This is always done at the quote phase of any project. And yet it remains the single most reason for wrong estimations.

One of my project was supposed to be based upon an earlier released product. Our project was a cluster from automotive domain. The target was to change the processor to the latest version and no change in application software. Technically, update the BSP (base support package - driver layer in embedded SW) and we are done.

Just for fun, submit this below poll based on your experience.

The application did not change as decided. Make a wild guess what could have happened.

The requirements team had to start from a clean slate (no reuse of requirements) and in order to define requirement the team did reverse engineering to the application based on the behavior. Suddenly, the same application did not remain the same at all.

You might say the application behavior was the same, how could this have an impact on requirements. It was the same largely, but the nitty-gritty turned the SW world upside down. Now we had to now update the ‘reuse’ SW to match the new requirements.

E.g. A requirement - press a button for 10 seconds and then take action. Existing reused SW was taking action after 10 and button released. New requirement - take action after 10 seconds, ignore button release.

This appears minor, but to incorporate the change we had to add a new software path (increase MC/DC) and add guards for the next action mapped to the button. There were similar changes carried in hardware as well, eventually spread like wildfire.

There was a good amount of debate around it. The strategy to reverse engineer was always there, but the impact could not be foreseen and whoever did estimation could not have any clue the amount of havoc that will be followed. This resulted in project cost significantly overrun, project in red from day 1 and SW team escalations.

Best way to estimate

Let’s explore what could be done, so we are able to estimate more realistically. I am considering the most common scenarios below. Note that the list is not comprehensive, it is only meant as food for thought.

1. With Base - Similar programs are executed

   1. Base with changes

      1. Processor

      2. hardware section

      3. libraries

      4. …

2. Without Base - Complete new development

With Base

In this case, we have a timeline of previously executed project with similar requirements.

While considering base, ensure that whether it was a new product development (NPD) or reuse or anything in-between. As a starting reference, the maximum time would be the same as that of the base program.

Next step, check each sub topic and review the estimations.

E.g. The base program is NPD, one section is to calculate the software effort to create a library A. If this library is to be reused with little changes then you could consider the 10% efforts on integration. If this library is to be used with 25% changes, then the efforts will be directly linked to whether you got the same developer or not.

Extend this logic to all subsection on what is being changed.

Without Base

No basis for any evaluation, what could be the estimate.

In this case, consider the no of modules you plan to develop. List the modules, go through each of them, evaluate is it complete new development or could be reused from partially. This will be a long process, but the figure will be more realistic. If not realistic figure, it will help you to identify the weakness for development of a particular module(s). This will help to plan much better and assign the right resources from day one.

Summary

Estimation is hard, try to evaluate at deeper level. Remember, ‘Devil is in the details’. Do peer reviews with other teams. Strictly go through lesson learned and filed issues. While running a project, try to review the original plan and the current plan in order to mark what went off track and what caused it. This you could add to Wrong lesson learned section or good if went the other way.

Leave a comment