Microelectronics world news

A simple circuit adds a relevant status-reporting bit to the device’s existing already-sizeable capabilities suite.

As described in its datasheet (PDF), the DRV103 is a (mostly) complete, robust, versatile, and efficient solution for solenoid and other power driver applications. However, there’s one trick missing from its sleeve. It lacks the ability to detect and report open-load faults in which the driven load has come adrift or is missing its connection to the power source, or the coil winding has come open or has otherwise lost continuity.

Wow the engineering world with your unique design: Design Ideas Submission Guide

The 103 falls out of its shrink wrap with built-in over-current and over-temperature detection and protection already in place. The logic-level OK-status flag output goes to zero when an energize command is issued and such an error occurs. So, this variety of mishap and mayhem is already adequately covered. No need for rework there.

But obviously, if the driver attempts to energize the load when the load’s connections are broken, nothing useful will happen. And, in an unmodified 103, neither before nor after the failed attempt will any diagnostic error indication be sent to the controller, which will therefore happily but erroneously assume its orders are continuing to be obeyed. This might not be so good, particularly if the application is critical. And at the end of the day, aren’t they all?

Figure 1 shows a (reasonably) simple modification to address this shortcoming.

Figure 1 The absence of V+ at OUT when Input = 0 causes “wired-or” Status OK bit to be pulled low by Q2, indicating the open-load error condition. A connected GPI pin should be configured for passive pullup.

Here’s how it works.

When Input is pulled low by the controller, typically a µC general-purpose (GP) output bit, Q3 turns off, releasing Q1’s collector. Since Input being low also turns the DRV104 internal transistors off, the driver’s OUT pin will now float high or low depending on whether (or not) an intact connection to V+ is established through a properly connected load. This will turn Q1 on (or off), and Q2’s base along with it.

If a good V+ connection exists, Q1 will now turn on, turning Q2 off, releasing Status OK and causing a connected GP input bit to go true, sharing the good news with the controller.

Otherwise not.

Stephen Woodward‘s relationship with EDN’s DI column goes back quite a long way. Over 200 submissions have been accepted since his first contribution back in 1974.  They have included best Design Idea of the year in 1974 and 2001.

Related Content

• 8 to 48 volt PWM relay/solenoid driver finds fault, pinches power
• Booster circuit enables reliable solenoid operation
• The overcurrent limiting transistor fails before anything else!
• Three discretes suffice to interface PWM to switching regulators
• Automotive low side output switch architecture suitable for 8 to 48 volt buses and beyond

The post Adding open-load fault detection to the DRV103 PWM driver appeared first on EDN.

Let’s explore the many application angles of one of the most widely used WiFi modules, through a prototyping board that can host and manage sensors and actuators, all testable with firmware we wrote specifically for the purpose. First instalment.

Modules based on the Espressif ESP32 SoC are highly regarded by designers of applications connected over a WiFi wireless interface, and that is why we have seen them in use for years, and use them ourselves in various projects. Precisely because of their importance and the strong demand from developers and experimenters, we decided to build a demoboard that makes it possible to create firmware both to test a wide range of sensors and to learn how to program the ESP32 and build connected applications, first and foremost in the Internet of Things space.

The board we will use has at its core a wireless module based on the ESP32, and also provides a whole set of headers (connectors) for plugging in various breakout boards and modules that act as its peripherals, namely pressure, ultraviolet, air quality, lightning and gesture sensors plus an NFC-compatible RFID reader. Completing the board is a user interface made up of an OLED display, a set of buttons and LEDs, all configurable to achieve a specific interfacing mode.

Let’s see right away what it is, analysing the board in detail before moving on to the description of the corresponding circuit diagram.

The board

Our demoboard is based on the Board with ESP32 (code YB555), fitted with a MicroUSB connector that is used for programming but can also supply power to the whole demoboard, provided the current required does not exceed a certain value that the ESP32 board can deliver. Alternatively, 12V can be supplied to the PWR power plug, and then it is the demoboard’s regulator U2 (code MP1584ENDCDC) that produces the 5V for the rest of the circuit. In Fig. 1 you will find the pin-out of the ESP32 module in question.

The following modules can be hosted on our demoboard:

• Air quality sensor code SGP30CO2 (U3)
• Lightning sensor code FT1324M (U4)
• Gesture sensor code APDS9960BOUT (U5)
• UVB sensor code GYLM8511 (U6)
• Pressure sensor code BMP280 (U7)
• NFC/RFID reader code PN532 (U8)
• 0.96″ OLED display code OLED096C or code OLEDGVSCSD (OLED1)
• 5V relay (RL1)
• Red LED (LD1)
• Green LED (LD2)
• 5 buttons (P1, P2, P3, P4, P5)
• BreadBoard
• Provision for connecting 3.3V SPI devices (SPI)
• Provision for connecting other 3.3V I²C devices (I²C)

Additional connectors and external peripherals

Beyond what is already provided above, other devices can be connected by making use of the free pins of the ESP32 board. The pins with no connection are D1/TX0, D2, D3/RX0, D34, plus the SPI pins that are not used for connection to any breakout board.

As for the connectors intended for connecting breakout boards and sensors external to the board, we have provided these elements:

• Liquid turbidity (clarity) sensor code TORBISENS (CNU9)
• PIR sensor code PIRMOD / code MINIPIRMOD (CNU10)
• Servo motor, for example code SERVO206 (CNU11)

All the codes given in brackets refer to products for quicker identification. In any case, let’s take a look at the board’s circuit diagram, shown in full on the page next to this one.

Circuit diagram

The circuit, as you can see, is centred on the ESP32 board, designated U1, which receives its main power through the Vin pin; its internal regulator provides a stabilised 3.3V that powers the interface boards that can be fitted to the demoboard and run on that voltage, that is, all those that can be hosted on-board except U6.

The Vin contact of U1 is powered with the 5V that the main power supply derives from the input voltage applied to the PWR DC power jack; the input voltage is first filtered by capacitors C1 and C2 and then stepped down to 5V by regulator U2, which is an MP1584ENDCDC DC/DC step-down module, capable of delivering 3A of current at a stabilised 5V: enough to run all the breakout board modules supported by our demo board.

The 5V output (suitably filtered by C3, C4 and C11 to knock down the switching residue of the switching module) powers the modules that run at that voltage (the UVB module) and the connectors for the servo (CNU11), PIR (CNU10) and external turbidity sensor (CNU9), as well as the relay coil, which is switched by the NPN transistor T1 under the command of the ESP32 module’s D32 I/O line. From RL1 (whose coil has been fitted with an antiparallel diode to protect the collector junction of T1 when it turns off) we make the three changeover contacts available, so as to handle various types of load and various operating conditions; the relay is an actuator peripheral that can be associated, for example, with the sensors detecting that certain thresholds have been exceeded, or with the reading functions of the RFID/NFC module.

OLED display and I²C communication

The display on the board is a small OLED that can be interfaced over the I²C bus, used several times in our projects for its versatility, its low cost and the availability of dedicated Arduino libraries for driving it. It is the OLED096C: a module with a 128×64 pixel blue OLED (Organic Light Emitting Diode) display, I²C interface, SSD1306 graphics controller, viewing angle of about 180°, Arduino compatible.

The library provided for the graphics controller has a modular structure and some modules can be excluded from compilation to reduce the use of Flash memory space. It requires very little RAM and supports, besides I²C bus communication, SPI as well: in the first case it runs a software implementation (Wire library, AVR Twi, Linux i2c-dev) and in the second a 4-wire SPI implementation (Arduino SPI library, AVR Spi, AVR USI module).

The controller allows you to create primitive graphics functions (lines, rectangles, pixels, bitmaps) and text printing (using characters of different sizes; you can use GLCD Font Creator to create new characters).

The display is managed by module U1, through the I²C bus shared with other on-board units such as modules U3 (air quality sensor), U4 (lightning detector), U5 (gesture detector), U7 (pressure sensor), U8 (RFID/NFC module), and brought outside through the connector labelled I2C, to interface the demoboard with external units. In the circuit diagram you can see that OLED1 is powered through two three-way jumpers that must be set one complementarily to the other; the purpose is to allow the various versions available on the market to be fitted, since they may have the + and – power pins (1 and 2) swapped; so if pin 1 is positive, you close jumper J1 on +3V3 and J2 on GND, while if it is negative, you do the opposite (J1 on GND and J2 on +3V3).

SPI bus, LEDs and buttons

Our ESP32 module also implements a 4-wire SPI bus (MISO, MOSI, SCK and CS), useful for interfacing the demoboard with SPI devices (in this case the connector of the same name is used) and various sensors; on that point it should be said that although the on-board sensor U4 supports bidirectional SPI/I²C bus communication, we preferred to interface it to U1 over the I²C bus already described, which uses the ESP32’s D21/SDA and D22/SCL lines. The complete SPI bus, on the other hand, uses the ESP32’s I/O lines D13 (MOSI), D12 (MISO), D14 (SCK) and D15 (CS-Chip Select), and on the relevant connector we also bring out GND and the +3.3 volt supply.

Besides the connectors and modules described so far, the demoboard carries two multifunction LEDs driven by the D25 and D26 lines of module U1 (in USB communication they indicate the switching of the data channel) and manageable by firmware according to the desired application; to complete the circuit we have provided five normally open single-pole buttons that can be used, for example, to set values or thresholds, or to navigate on-screen menus; not by chance, the keys have these functions associated with them:

• P1 = OK
• P2 = UP
• P3 = DOWN
• P4 = LEFT
• P5 = RIGHT

And their arrangement on the printed circuit board somewhat echoes that of a classic joypad. If you intend to use the buttons for other functions, you are free to do so (by modifying the example firmware that will be proposed from time to time among the examples) and rename them according to your needs.

To complete the demoboard we added a small 170-contact breadboard in the centre, which can be used either to wire up breakout boards using Arduino jumpers and the SIL contacts or connectors of the on-board modules, or to connect active and passive components to specific parts of the circuit, for building small circuits of your own.

Building it in practice

Good, at this point we have described the demo board, so we can move on to the construction side: building the demoboard starts with the double-sided printed circuit board on which all the necessary components will sit. To make the project more accessible to makers, these are all THT, that is through-hole or traditional mounting, if you prefer. So once you have the printed circuit board, you can build the board with a minimum of equipment: just an electronics soldering iron, some solder wire and a pair of side cutters to trim the leftover component leads.

Once the board for photo-etching is ready (that is, after you have obtained it from the PCB manufacturing service, starting from the two copper-side traces available for download), you can move on to the actual assembly.

Start by placing and soldering the lowest-profile components, so resistors, LEDs, non-polarised capacitors, pin strips and female strips for the connections and for the modules that will be hosted on board, then the LEDs, the buttons and the electrolytic capacitors, and finally the power jack. Then fit the breadboard, which is simply glued in the position shown by the assembly drawing, using double-sided tape because it has no pins or leads. For polarised components (semiconductors and electrolytics) you must scrupulously respect the insertion direction shown in the assembly drawing you will find in these pages.

Don’t forget to pay attention to the polarity of the OLED display’s power contacts and to set the corresponding jumpers J1 and J2 accordingly (as already explained a few paragraphs back) so that power is applied with the correct polarity.

To power the board you need to use a supply source (not necessarily stabilised) that delivers a DC voltage of 8 to 12 volts and a current of at least 1A (in reality the current depends on how many modules you fit and which ones).

Remember that although the photos in these pages show the demoboard fully populated, you don’t actually need to fit all the modules, only the ones you will be working with at any given time; it goes without saying that two must always be present: the DC/DC (U2) and of course U1, that is the module containing the ESP32 SoC.

Component list:

• C1, C4, C6, C8, C10, C11: 100 nF ceramic
• C2, C3, C5, C7, C9: 100 µF 16 VL electrolytic
• D1: 1N4148
• LD1: 5 mm red LED
• LD2: 5 mm green LED
• P1, P2, P3, P4, P5: Microswitch
• R1, R2: 330 ohm
• R5: 6.8 kohm
• R6: 3.3 kohm
• R3: 4.7 kohm
• R4: 10 kohm
• RL1: 5V relay, 1 changeover
• T1: BC547
• U1: ESP32-WROOM-32 breakout
• U2: 5V/3A step-down module
• U3: SGP30 air quality module
• U4: AS3935 lightning sensor
• U5: PDS-9960 gesture module
• U6: UVB sensor module
• U7: pressure sensor module
• U8: NFC/RFID module
• OLED1: 0.96″ OLED display

Miscellaneous:

• 2-way male pin strip, 2.54 mm pitch (4 pcs.)
• 3-way male pin strip, 2.54 mm pitch (5 pcs.)
• 4-way male pin strip, 2.54 mm pitch (1 pc.)
• 6-way male pin strip, 2.54 mm pitch (3 pcs.)
• 7-way male pin strip, 2.54 mm pitch (1 pc.)
• 15-way male pin strip, 2.54 mm pitch (2 pcs.)
• 2-way female pin strip, 2.54 mm pitch (4 pcs.)
• 4-way female pin strip, 2.54 mm pitch (2 pcs.)
• 5-way female pin strip, 2.54 mm pitch (1 pc.)
• 6-way female pin strip, 2.54 mm pitch (2 pcs.)
• 7-way female pin strip, 2.54 mm pitch (1 pc.)
• 15-way female pin strip, 2.54 mm pitch (2 pcs.)
• 4-way female pin strip, 2.54 mm pitch, 90° (1 pc.)
• Jumper (2 pcs.)
• 3-way terminal block, 5 mm pitch
• 170-contact breadboard
• Power plug
• S1632 printed circuit board (140×110 mm)

Arduino IDE setup

Once you have completed your demoboard at the hardware level, you can focus on the software side, which covers creating the applications and programming the ESP32 module.

First of all you will need to install the ESP32 board so that it can then be programmed from the IDE. To do this, open the IDE, then from the “File > Preferences” menu enter the string https://dl.espressif.com/dl/package_esp32_index.json in the Additional Boards Manager URLs box (Fig. 2).

Having done that, from the “Tools > Board” menu you must issue the “Boards Manager” command and select your ESP32 board, that is type ESP32 in the text box at the top and proceed with installing the ESP32 by Espressif Systems board package (Fig. 3).

Now, again from the “Tools > Board > Boards Manager” menu, choose the “DOIT ESP32 DEVKIT V1” board as shown in Fig. 4.

Everything is ready for programming, so from this point on you can write the code needed to manage the breakout board you are interested in. On that note we have already made available a set of example sketches for each breakout, so you will always have a starting point that certainly simplifies developing custom code. The folders with the sketches available for download are the ones shown in the screenshot in Fig. 5. In each individual example’s folder you will find the library paired with it, where the code requires one. Also, in every folder there will be an “info.txt” file that briefly explains the purpose of the example.

For almost all the examples you will need to have the 0.96″ OLED display module fitted; on that note, remember that on board you can use either OLED displays with the GND/VCC/SCL/SDA pinout, or those with a VCC/GND/SCL/SDA pinout, simply by configuring the two jumpers J1 (for pin 1) and J2 (for pin 2) so that GND rather than VCC is brought to pin 1 or 2 of the display, depending on the display installed.

First application: water sensor

This application example consists of reading the “turbidity” value of water using the specific sensor that can be connected to strip CN9.

This connector can also be used to read a voltage of up to 5V, since there is a divider at the input that lowers the voltage to a maximum of 3.3V; this reduction is necessary because the corresponding ESP32 input tolerates a normal voltage of 3.3V and a maximum of 5V, beyond which the ESP32 module is damaged.

The sensor used is the 9145-TORBISENS (Fig. 6) and it consists of the actual sensing element, to be partially immersed in the water whose clarity or turbidity you want to detect, and a signal conditioning and interface board, which will provide a digital or analogue signal and which you must connect to connector CNU9.

The sensor is able to detect particles suspended in water (or another liquid, as long as it is not chemically aggressive or a solvent) by measuring light transmission and the dispersion rate, which changes with the total amount of total suspended solids (TSS) in the water. As the TSS (Total Suspended Solids) increases, the liquid’s turbidity level rises. It has an analogue and a digital output.

When using this sensor, it is worth remembering that only the transparent plastic part with the two “prongs” should be immersed, because the upper part of the probe (the one where the cable connects) is not watertight. The temperature of the liquids in which the sensor can be immersed must be between +5°C and +90°C: bear this in mind when using it.

Once the sensing part has been introduced into the water, the sensor provides the corresponding value in a time of the order of 500 ms. If the output is set to analogue, it provides a voltage from 0 to 4.5 V inversely proportional to the liquid’s turbidity; if instead it is set to digital, the turbidity threshold can be adjusted using the dedicated trimmer on the interface board (0=turbid; 1=clear).

The sketch we suggest you upload to use the water turbidity sensor is the one shown in Listing 1.

Listing 1

/**************************************************************************

This is an example for our Monochrome OLEDs based on SSD1306 drivers

This example is for a 128×64 pixel display using I2C to communicate

3 pins are required to interface (two I2C and one reset).

Adafruit invests time and resources providing this open

source code, please support Adafruit and open-source

hardware by purchasing products from Adafruit!

Written by Limor Fried/Ladyada for Adafruit Industries,

with contributions from the open source community.

BSD license, check license.txt for more information

All text above, and the splash screen below must be

included in any redistribution.

**************************************************************************/

#include <SPI.h>

#include <Wire.h>

#include <Adafruit_GFX.h>

#include <Adafruit_SSD1306.h>

#define SCREEN_WIDTH 128 // OLED display width, in pixels

#define SCREEN_HEIGHT 64 // OLED display height, in pixels

// Declaration for an SSD1306 display connected to I2C (SDA, SCL pins)

// The pins for I2C are defined by the Wire-library.

// On an arduino UNO: A4(SDA), A5(SCL)

// On an arduino MEGA 2560: 20(SDA), 21(SCL)

// On an arduino LEONARDO: 2(SDA), 3(SCL), …

#define OLED_RESET -1 // Reset pin # (or -1 if sharing Arduino reset pin)

#define SCREEN_ADDRESS 0x3C ///< See datasheet for Address; 0x3D for 128×64, 0x3C for 128×32

Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);

#define NUMFLAKES 10 // Number of snowflakes in the animation example

#define LOGO_HEIGHT 16

#define LOGO_WIDTH 16

const int Sens = 33;

void setup()

{

Serial.begin(9600);

// SSD1306_SWITCHCAPVCC = generate display voltage from 3.3V internally

if(!display.begin(SSD1306_SWITCHCAPVCC, SCREEN_ADDRESS)) {

Serial.println(F(“SSD1306 allocation failed”));

for(;;); // Don’t proceed, loop forever

}

// Show initial display buffer contents on the screen —

// the library initializes this with an Adafruit splash screen.

display.display();

delay(2000); // Pause for 2 seconds

// Clear the buffer

display.clearDisplay();

display.setTextSize(2); // Draw 2X-scale text

display.setTextColor(SSD1306_WHITE);

display.setCursor(5, 0);

display.print(“** Test **”);

display.setCursor(20, 30);

display.print(“ Analog “);

// Show the display buffer on the screen. You MUST call display() after

// drawing commands to make them visible on screen!

display.display();

delay(2000);

// display.display() is NOT necessary after every single drawing command,

// unless that’s what you want…rather, you can batch up a bunch of

// drawing operations and then update the screen all at once by calling

// display.display(). These examples demonstrate both approaches…

/*

// Invert and restore display, pausing in-between

display.invertDisplay(true);

delay(1000);

display.invertDisplay(false);

delay(1000);

*/

pinMode(Sens,INPUT);

}

void loop()

{

int val_adc = 0;

float val_tens;

String txt_msg;

val_adc=analogRead(Sens);

val_tens = float(500)/float(4096);

val_tens = float(val_tens) * float(val_adc);

val_tens = float(val_tens) / float(100);

txt_msg=””;

txt_msg = String(val_tens,4) + “V”;

Serial.println(txt_msg);

OLED_Message(“5V max for CNU9-OUT”,txt_msg);

delay(500);

}

void OLED_Message(String text_display1, String text_display2)

{

int lunghezza = 0;

display.clearDisplay();

display.setTextSize(1); // Draw 2X-scale text

display.setTextColor(SSD1306_WHITE);

display.setCursor(0, 20);

lunghezza = text_display1.length();

lunghezza=21-lunghezza;

lunghezza=lunghezza/2;

for (int i=0;i<lunghezza;i=i+1)

{

display.print(“ “);

}

display.print(text_display1);

display.setCursor(0, 40);

lunghezza = text_display2.length();

lunghezza=21-lunghezza;

lunghezza=lunghezza/2;

for (int i=0;i<lunghezza;i=i+1)

{

display.print(“ “);

}

display.print(text_display2);

display.display();

} As for the connection between the sensor, the supplied interface board and the demoboard, the wiring diagram shown in Fig. 7 applies; in the image, the wire colours are red for +5V, black for ground (GND) and blue for the signal.

Conclusions

Well, with this first example of use we end our overview of the ESP32 demoboard; in the next instalment we will present new sketches and new applications involving both the on-board sensors and modules and modules that can be connected externally through the side connectors.

The demoboard presented in these pages was created to develop and prototype “connected” applications that exploit the WiFi wireless interface to publish or transfer data relating to the sensors and readers present on board or connected externally through the connections it provides; the same parameters can be partly managed and displayed, as a monitor, by the on-board OLED display.

The rich set of sensors makes the board an ideal candidate for the development and prototyping of applications in the IoT field, precisely because of its function as a bridge between sensor data and the Internet or a local wireless connection. With a few extra lines of code it is also possible to perform a minimum of Edge Computing so as to aggregate data from several sensors and save bandwidth in transmission to the Network.

Related products

• Analog Water Turbidity Sensor

The post ESP32 Demoboard: a Prototyping Board for Sensors and Actuators (Part 1) appeared first on Open Electronics.

As spacecraft and satellites become more autonomous and rely on software to perform complex tasks, they need faster and more reliable onboard computing systems. These systems must also withstand harsh space conditions while maintaining security and dependable performance. Microchip Technology has announced several key developments in its PIC64-HPSC high-performance space computing series. The 64-bit multicore RISC-V platform is designed to support spacecraft, satellites and other critical space missions that require advanced processing capabilities.

Early radiation tests on Microchip’s radiation-hardened PIC64-HPSC1000-RH processor have shown that it can withstand a total ionising dose of up to 200 krad(Si). It also passed single-event latch-up (SEL) testing at a particle energy level of 78.2 MeV·cm²/mg under specified operating conditions. During testing, the system controller continued to operate reliably, with no uncorrected errors or external resets required in the tests completed so far. These results indicate progress towards making the processor suitable for radiation-intensive space missions, including those involving low Earth orbit, the Moon and Mars.

“Our vision for PIC64-HPSC was to develop a modern, high-performance computing platform capable of enabling the next generation of civil, commercial, scientific and defense space systems,” said Kevin So, vice president of Microchip’s communications business unit. “The combination of operational silicon, radiation-characterization results and customer evaluation activity demonstrates continued execution against that vision and marks an important step in the maturation of the platform.”

Through the PIC64-HPSC Early Access Program, participating customers have been evaluating silicon and development kits, and beginning application development with supporting software, tools, technical resources and direct engineering assistance from Microchip. A growing ecosystem of board partners is also developing PIC64-HPSC-based VPX and VNX+ computing platforms, providing additional paths for system developers to integrate the processor into future space systems. The Early Access Program can help space-system developers reduce program risk and advance application development.

Initial silicon performance measurements are in line with program objectives, providing a foundation for increasingly compute-intensive workloads such as onboard autonomy, high-performance payload processing, Earth observation and intelligence, secure communications, spacecraft control, scientific exploration and edge AI. By processing more sensor and mission data onboard, future spacecraft can reduce dependence on communications bandwidth, shorten decision-making latency and respond more rapidly to changing mission conditions. The importance of advanced onboard processing is also reflected in NASA’s FY26 Civil Space Shortfall Prioritization, which ranked advanced onboard computing for space operations as the third-highest civil space technology shortfall.

PIC64-HPSC is designed as a scalable computing foundation for a broad range of next-generation space systems. Its 64-bit multicore RISC-V architecture supports the industry’s move toward more open and scalable models for onboard autonomy, software-defined spacecraft, distributed processing, deterministic communications and heterogeneous computing.

PIC64-HPSC originated from NASA and JPL’s assessment of future spaceflight computing requirements and awarded the HPSC contract to Microchip in 2022. Today, operational silicon, customer evaluations and early radiation-characterization achievements reflect the program’s progress to date.

The HPSC program helped establish the foundation for Microchip’s 64-bit computing portfolio, which the company has since expanded its portfolio of PIC64 MPUs addressing performance requirements across a broad range of markets.

The post Microchip Achieves Key Milestones in PIC64-HPSC Spaceflight Computing Development appeared first on ELE Times.

Beyond Physical Perimeters: Transitioning to Attack Surface Management

With the rapid emergence of Software-Defined Vehicles (SDVs) and Advanced Driver Assistance Systems (ADAS), modern automobiles have evolved into distributed computing platforms—effectively data centres on wheels. This transformation requires a fundamental shift in how the industry conceptualises automotive security.

Traditional security models relied on physical perimeters, drawing a boundary around assets and protecting them within a contained enclosure. Much like cloud computing disrupted enterprise physical perimeters, automotive software renders physical containment obsolete. Security engineering must instead adopt an Attack Surface Management model.

Rather than attempting to enclose the vehicle within a physical parameter, Attack Surface Management evaluates every external connection point through which an attack vector could enter:

• OEM Cloud Connections: Over-the-air (OTA) update channels and telemetry pipelines.
• Mobile Applications: User management apps interacting with vehicle functions via APIs.
• Charging Infrastructure: Physical and digital interfaces at EV charging stations.
• Third-Party APIs: External software services pulling or transmitting vehicle telemetry.
• In-Vehicle Infotainment (IVI) & Connectivity: Local wireless protocols including Bluetooth and Wi-Fi.

Recent real-world incidents highlight the dangers of flawed perimeter assumptions. These include remote disabling of commercial auto-rickshaws via unauthenticated, open wireless interfaces. Secure vehicular architecture requires continuous validation: verifying whether the sender of an instruction is authorised and determining whether the receiving Electronic Control Unit (ECU) should execute the request.

Cybersecurity as a Brand Differentiator and Hygiene Metric

In enterprise IT, a cybersecurity breach typically results in data loss, service downtime, or administrative inconvenience. In the automotive domain, a breach triggers a cyber-physical event, directly impacting physical safety and human lives.

Security researchers have repeatedly demonstrated remote exploits capable of manipulating navigation systems, spoofing GPS coordinates, or executing unauthorised API calls across thousands of connected vehicles globally. Significantly, many of these vulnerabilities stem not from flaws in the primary vehicular control systems, but from exploits within integrated third-party software APIs accessed over the internet.

As consumers become increasingly tech-savvy, cybersecurity has shifted from an invisible technical specification to a foundational brand hygiene issue. Regardless of a vehicle’s luxury features, performance metrics, or post-purchase service offerings, unmitigated cybersecurity vulnerabilities threaten brand trust. Furthermore, as Over-The-Air (OTA) software updates become standard, managing update integrity is critical to preventing vehicle bricking or operational failures on the road.

Implementing Zero Trust Architecture (ZTA) and Machine-to-Machine Authentication

As autonomous and connected vehicles advance, managing Machine-to-Machine (M2M) and Vehicle-to-Vehicle (V2V) identity authentication requires implementing Zero Trust Architecture (ZTA).

Zero Trust operates under the explicit assumption that a network breach has already occurred (“trust no one”). Within a vehicle’s internal bus and external communication channels, ZTA eliminates implicit trust and enforces strict authentication protocols:

• Machine-to-Machine Identity: Every interaction between onboard ECUs, adjacent vehicles, and external road infrastructure requires explicit identity verification and authorisation.
• Fine-Tuned Role-Based Access Control (RBAC): ZTA enforces strict boundaries between informational data and physical control systems. For example, while a vehicle may accept V2V telemetry regarding downstream traffic congestion, that external data stream must never be granted execution rights to alter onboard steering or braking systems directly.

Implementing Zero Trust across vehicular systems requires embedding continuous validation across every architectural layer—from physical hardware root-of-trust to software execution.

Post-Quantum Encryption, VSOCs, and the “Cyber Crumple Zone”

To protect passengers, pedestrians, and data privacy against long-term threat vectors, original equipment manufacturers (OEMs) must implement proactive defense strategies:

Post-Quantum Cryptography (PQC)

With the eventual realisation of quantum computing, legacy encryption algorithms risk widespread decryption. OEMs must begin transitioning toward Post-Quantum Cryptography standards (such as NIST-approved PQC frameworks) to ensure long-term data protection.

Hardware Security Modules (HSM)

Relying solely on software-based trust keys creates structural vulnerabilities. Physical Hardware Security Modules (HSMs) must serve as the immutable, hardware-backed Root of Trust (RoT) for all cryptographic operations within the vehicle.

Vehicle Security Operations Centres (VSOC)

Continuous monitoring through specialised Vehicle Security Operations Centres (VSOCs) allows OEMs to detect telemetry anomalies across fleet deployments in real time. It also helps initiate defensive countermeasures before vulnerabilities can be exploited at scale.

The “Cyber Crumple Zone” Analog

Traditional automotive engineering uses physical crumple zones to absorb impact energy during a collision, preventing physical force from penetrating the passenger cabin. Automotive software architectures require an analogous Cyber Crumple Zone. By enforcing strict hardware and software compartmentalisation, a cyber breach within a non-critical subsystem (such as the IVI or a third-party app interface) is strictly contained. This prevents lateral movement into critical vehicle dynamics, steering, or braking controls.

Mitigating Security Debt, Ensuring Data Privacy, and Framework Alignment

Connected vehicles store extensive personal data, including frequent locations, navigation histories, and home automation credentials (such as automated garage door keys). As privacy regulations like India’s Digital Personal Data Protection (DPDP) Act come into force, OEMs must treat vehicle telemetry under strict data privacy frameworks.

Managing Automotive Security Debt

The automotive development lifecycle spans 5 to 10 years, followed by an operational vehicle lifespan of another decade or more. This long timeline introduces significant security debt—where aging onboard hardware and software architectures remain in service long after modern threat vectors have evolved.

To mitigate security debt, OEMs must adopt a risk-based management approach:

• Establishing continuous validation pipelines that extend beyond initial lab certifications to monitor long-term operational resilience on the road.
• Managing technology updates lifecycles to patch legacy systems as vulnerabilities surface over time.
• Aligning internal risk frameworks with established automotive cybersecurity standards (such as AIS 189/190 and ISACA risk maturity models).

By combining Attack Surface Management, Zero Trust principles, hardware-backed root-of-trust, and compartmentalised cyber crumple zones, the automotive industry can build software-defined vehicles that remain secure throughout their operational lifespans.

The post “We’re Redefining Vehicular Security in Software Defined Vehicles” — R.V. Raghu, Director, Versatilist Consulting India appeared first on ELE Times.

PaperFlux is a small connected object that once a week prints a summary of the user’s GitHub activity on thermal paper: stars, followers, commits from the last seven days, languages and main repositories. The board downloads a black-and-white PNG image generated by a server over HTTPS and sends it to a 58 mm thermal printer. The project is by Alban Petit and covers the period from October 2024 to September 2026. It is a complete example of a connected object that brings together custom electronics design, embedded firmware, a production web service and mechanical modelling.

The board measures 33.55 × 50.05 mm and has four M2 mounting holes. The total PCB thickness is 1.58 mm, with an ENIG finish. The routing counts a little over 300 segments on the front side, around thirty on the back and about a hundred vias. The heart is an Espressif ESP32-C3-MINI-1, flanked by a Diodes AP33772S controller in a WQFN-24 package with 0.5 mm pitch and I²C address 0x52.

USB-C PD power and the 3.3 V rail

The board is connected to a USB-C Power Delivery charger and negotiates a voltage of 9 V, with 5 V as fallback, which powers both the electronics and the printer. The AP33772S controller talks to the charger on the CC1 and CC2 lines, where the pull-down resistors R4 and R5 are 5.1 kΩ. It also measures current through the R6 shunt of 5 mΩ and monitors temperature via the NTC1 thermistor.

Once the voltage is established, the AP33772S closes the two MOSFETs Q1 and Q2, both DMN3009SFG. The ESP32-C3 is powered through the AP33772S switch: if a protection trips and cuts the output, the microcontroller shuts down together with the printer. The AP63203 converter produces a 3.3 V rail with current up to 2 A, using a Würth WE-MAPI 3015 inductor of 3.9 µH. The connector is a JAE DX07S016JA1R1500. A TI TPD4E02B04 also comes into play for line protection and, on the I²C bus, a TI PCA9306 level shifter.

The ESP32-C3 firmware and PNG streaming to the print head

The firmware connects to Wi-Fi, synchronises the clock via NTP and checks every minute whether it is time to print a receipt; by default the receipt is due once a week. When the time comes, the board calls the web service endpoint. The server collects the GitHub statistics, lays out an HTML template in a headless Chromium and converts the screenshot into a black-and-white PNG exactly as wide as the print head. The PNG generated by the server is 384 px wide and in 1-bit format.

The firmware decodes the PNG on the fly and sends it to the printer line by line. The DP-EH400/2 thermal printer has a print width of 384 dots and a TTL interface, with a UART connection at 9600 baud. The project uses KiCad for the schematic and layout, PlatformIO with Arduino on ESP32-C3 for the firmware, and on the server side Ruby 3.3 with Sinatra, Ferrum, ImageMagick, Kamal, Docker and GitHub Actions. Mechanical modelling is done in FreeCAD.

• Espressif ESP32-C3-MINI-1, the microcontroller with Wi-Fi
• Diodes AP33772S, the USB-C Power Delivery controller with I²C address 0x52
• 2 × DMN3009SFG, the MOSFETs that close the output
• Diodes AP63203, the converter that produces the 3.3 V rail up to 2 A
• Würth WE-MAPI 3015 of 3.9 µH, the converter inductor
• TI PCA9306, the I²C level shifter
• TI TPD4E02B04, the line protection
• JAE DX07S016JA1R1500, the USB-C connector

Anyone who wants to rebuild the project will find the full account of the work, from the KiCad schematic to the web service, on the maker’s site. The text contains precise numbers: the 33.55 × 50.05 mm board, the 5 mΩ shunt, the 384 px PNG, the UART at 9600 baud. These are all figures that matter to anyone who has to replicate the same chain, from the USB-C connector to the thermal print head.

For assembly you need a USB-C PD charger capable of negotiating 9 V, a USB-C to USB-C data cable and a thermal printer compatible with the DP-EH400/2 format. For those starting from scratch with the ESP32-C3, a mini ESP32-C3 module is the simplest starting point to try the firmware before soldering the final board.

Source: https://albanpetit.com/post/paperflux/

Related products

• Mini ESP32-C3 module

The post PaperFlux: the thermal receipt printer that prints your GitHub activity appeared first on Open Electronics.

Infineon Technologies AG is setting up Europe’s first high-volume manufacturing facility for gallium nitride (GaN) power semiconductors using 300-millimetre wafers. The company plans to invest around €1.1 billion in its existing cleanroom facilities at its Villach site in Austria by 2034, using and upgrading the current infrastructure to expand production capacity more efficiently and at a lower cost. Manufacturing is expected to begin by the end of 2027. The investment aims to meet growing demand for energy-efficient power chips used in AI data centres, energy infrastructure, electric vehicles, robotics and consumer electronics. GaN semiconductors can improve power-conversion efficiency, reduce energy losses and enable smaller, more compact electronic systems.

Infineon is a leading developer of gallium nitride (GaN) power semiconductors. Two years ago, the company achieved a major technological milestone by successfully processing GaN wafers measuring 300 millimetres in diameter. These larger wafers can produce around 2.3 times more chips per wafer than conventional 200-millimetre wafers, making manufacturing more efficient and cost-effective. Infineon is now moving this technology into high-volume production to supply customers with next-generation power semiconductors.

“This substantial investment shows our clear commitment to strengthening the European semiconductor ecosystem and Europe’s technological sovereignty. By establishing high-volume manufacturing on 300-millimeter wafers, we will be the first company in the world to bring gallium nitride power electronics into volume production,” says Jochen Hanebeck, CEO of Infineon Technologies AG. “In doing so, we are paving the way for the widespread use of gallium nitride in a wide range of key applications in areas such as artificial intelligence, energy infrastructure, e-mobility and robotics. This new, state-of-the-art manufacturing facility translates innovation leadership into direct customer benefits.”

Christian Stocker, Federal Chancellor of the Republic of Austria: “With Infineon’s billion-euro investment, we are witnessing one of the largest single investments in the history of Austria’s high-tech industry. This is not only a strong commitment to Austria as a business location but also helps ensure that the future of the semiconductor industry will not be shaped solely in Asia or the United States, but also in Austria and Europe. Villach will thus become home to a globally unique production facility for one of the key technologies that will shape the future. This will strengthen our international competitiveness and secure jobs and value creation in Austria. After all, Austria may not be a country with unlimited natural resources, but it is a country with an unlimited wealth of talent. Our cutting-edge research sets international standards, and companies such as Infineon demonstrate every day how innovation made in Austria works. These are precisely the strengths we want to build on with our industrial strategy so that, by 2035, Austria will once again rank among the world’s top ten industrial nations.”

Wolfgang Hattmannsdorfer, Austrian Federal Minister for Economic Affairs: “Chips are as important to tomorrow’s economy as oil was to yesterday’s. Europe currently accounts for only around 10 percent of global chip production. For me, the conclusion is clear: We must also manufacture this key technology in Europe. Austria is already a leader in energy-efficient chips. Relative to our population, we rank first in the EU in business R&D spending in the semiconductor sector. With our industrial strategy, we intend to build on this lead and not only research new technologies but also manufacture them on an industrial scale. This benefits the entire economy: Statistically, every job in the chip industry can provide six additional jobs across the broader economy. That is why we intend to support Infineon’s new chip production with up to 319 million euros – subject to clear funding criteria for the location. This will ensure that public funds strengthen value creation and jobs in Austria over the long term.”

The investment in this first-of-a-kind technology is being supported under the European Chips Act. The European Commission approved €319 million in state aid. The formal funding commitment by the Austrian Federal Ministry for Economic Affairs, Energy and Tourism is expected within the stipulated time limits. By approving the funding from the Federal Ministry for Economic Affairs, Energy and Tourism, the European Commission is not only enabling the expansion of manufacturing capacities in Europe but is also generating positive spillover effects in related sectors – for example, through cross-border collaboration with universities and research institutions and improved access to innovative technologies and products for start-ups and small and medium-sized enterprises.

“Competitiveness and technological sovereignty emerge where excellent research is translated into industrial value creation. This is precisely where our flagship project comes in: From Austria, we are bringing innovation into industrial application, strengthening our technological leadership and securing highly skilled jobs. Microelectronics is a key industry with enormous leverage for the economy and society. The entire Austrian semiconductor ecosystem benefits – from research organizations and universities to industrial partners. We are thus sustainably strengthening Europe’s competitiveness and strategic autonomy in microelectronics,” emphasizes Sabine Herlitschka, CEO of Infineon Technologies Austria AG.

The investment strengthens Villach’s role as a global competence center for power electronics and new semiconductor materials. Infineon Austria currently employs around 5,800 people, approximately 4,800 of them at the Villach1 site. Together with universities, research institutions, start-ups and industry partners, Infineon forms the core of an internationally recognized microelectronics ecosystem in southern Austria. The establishment of the new 300-millimeter GaN manufacturing facility will also create positive synergies with the power electronics research and development activities located in Villach.

Gallium nitride is an advanced semiconductor material that can switch and convert electricity much more efficiently. This enables smaller, more powerful and more energy-efficient electronic systems with lower energy loss and reduced heat generation. Analysts expect the market for GaN power semiconductors to grow to approximately USD 3.5 billion by 2031, representing annual growth of around 35 percent between 2025 and 2031.2

The post Infineon to Build Europe’s First High-Volume 300mm GaN Power Semiconductor Manufacturing Facility appeared first on ELE Times.

havent touched electronics in forever (ended up doing consumer product rnd (mostly material science) for 8 years and wanted to get back to this im sharing something iv been working on and im sure its nothing compared to the complexity of things people make in this sub there was a concern in my family business -- counting fertilizer bags going into a truck essentially bags are weighed before loading so i managed to pull the signal out of the RS232 port of the weighing machine and using a micro controller count the bags and upload it onto the cloud i was able to add additional features as well (check if the bag is over weighed and sound a siren etc) right now its module based but it works -- hoping version 2 will have next to no modules and 100 percent components the final goal is to bring about IOT into the whole factory submitted by /u/95farfly [link] [comments]

submitted by /u/1Davide
[link] [comments]

Any engineer with hands-on experience is familiar with cables which are shielded with a woven, all-metal braid, seen in Figure 1. Braided shielding has been used for decades. It is widely available, has modest cost, and it works—at least up to a point.

Figure 1 This schematic of a cable using conventional braided shielding illustrates the RF barrier it provides; the illustration shows multiple basic-wire conductors, but the same concept is used with coaxial cables and twisted-pair cabling. Source: Stecker Express

The braid serves two complementary EMI functions in most cases. It attenuates emissions of electromagnetic energy from the cable, and, at the same time, it prevents interfering energy from reaching the cable. It’s used for cables carrying DC all the way to gigahertz signals. Shielding is used with coaxial cable, twisted pairs, multiconductor cable assemblies, and more.

Engineers have a love/hate relationship with cables that use a tightly woven conductive braid for shielding. On one side, it’s an essential passive component for maintaining signal integrity, and how can you put a price on that, especially when there seems to be no viable alternative. On the other side, it adds bulk, weight, cost, and routing challenges to the end-product.

Shielded cable also has termination challenges. Every hands-on engineer can tell “horror stories” of trying to cleanly terminate the shield to the connector, especially if it’s being done by hand without the right tools or jigs. Those tiny cut shards of braid that “fall” when trimming it can easily short the cable, and nearby circuit board, and cause general troubleshooting havoc.

The shielded-cable dilemma increases in today’s world of complex cabling in small spaces, with design emphasis on cable size, weight, and performance. Cables with conventional braided shields—almost always made of copper, but sometimes other metals such as aluminum are used—are relatively heavy and bulky.

Furthermore, the relative proportion of their overall weight and bulk increases compared to core cable size as the core that is being shielded shrinks down. That creates a dilemma for designers as gigahertz cables go down to millimeter-levels diameter, and the weight and bulk of the shielding soon become a significant design issue.

There’s even another insidious concern: performance. As frequencies reach in the multi-gigahertz range, the shielding performance of the braid decreases. The tiny voids in the woven braid become “open windows” to the short-wavelength RF energy. These shielded cables also restrict movement, can be difficult to handle and install, and their “shape memory” makes routing and rerouting more difficult.

Tighter weaves improve the situation somewhat, but at a cost in materials, flex, weight, and other factors.

Some cables use a solid foil as a first-layer shield, which is then covered with a braided shield. This improves RF shielding to nearly 100%, but further increases cost and weight and adds to termination complexity.

What can be done?

New shielding technologies and approaches are needed as cable applications shift. A vendor-authored article I saw highlighted the ARACON shielding system from Micro-Coax, a division of Amphenol. It’s based on a very different approach to creating the RF cage around the signal-carrying conductors.

Instead of woven metal braid, it uses lightweight, ultrathin, and extremely strong DuPont Kevlar fibers to create a textile-like material that then is coated with either nickel or silver (for solderability). It forms a composite shielding braid that is up to 80% lighter than copper, while still providing strong EMI/RFI protection, lightning protection, and mechanical robustness.

The conducting coating adheres to the fabric-like fibers to form a “wrapper” against electromagnetic energy. The result is a thin braid-equivalent that slips onto the cable core like a thin, open-ended, super-flexible sock. It can be used with coaxial cable, twisted pair, and even wire bundles, shown in Figure 2.

Figure 2 The ARACON shielding system uses a thin but super-tough fabric sock that slips over the conductor or wire bundle to be shielded. Source: Micro-Coax

To get a sense of the bulk differences, the density of aramid fibers is only 1.44 grams per cubic centimeter (g/cc), compared to copper at 8.9 g/cc. Even with the addition of the metal coatings, the density of fibers ranges from 3 g/cc to 5 g/cc. At the same time, the tensile strength of the aramid core, at 350 kilopounds per square inch (Ksi) is 3 to 10 times higher than that of traditional or high-strength copper cores (35 Ksi to 95 Ksi).

Its other attributes are flexibility and longevity. It has been tested to withstand over 50,000 flex cycles over a 180-degree arc; installs easily, as it cuts like fabric with standard tools; and it offers corrosion resistance (important in many real-world settings). Termination techniques are similar to those for wire-braided shields.

It meets or exceeds the many stringent mil/aero and space-related electrical, mechanical, and outgassing performance standards for shielding (it’s a long list), but with far less bulk and weight. Micro-Coax says it can be braided and fabricated by wire/cable vendors using standard metal-wire equipment and it supports crimping or banding, as well as soldering (if it’s silver plated).

The high surface-to-volume ratio of ARACON fibers contributes to effective RF EMI shielding, exceeding the performance of conventional shielding, as seen in Figure 3.

Figure 3 Despite its reduced bulk and weight, the Aracon approach offers approximately 20 dB greater attenuation compared to conventional copper braid (here, industry standard AA59569). Source: Micro-Coax

There’s a lot that is attractive about this shielding approach, which is not just a lab development but has been in use for over 10 years. It has been proven “in the field” in aircraft, space vehicles, and more.

While I couldn’t get comparative pricing—and direct one-to-one comparisons are difficult—I suspect it’s more costly than conventional metal-braided shielding. But I can see where the extra cost is justified in applications where lower weight and bulk, along with performance and flexibility, are more critical priorities than cost.

It feels weird to say “we’ve been a team all these years, but things have changed” to braided shielding. Still, sometimes we must acknowledge reality and move on in a somewhat different direction to meet new design demands and constraints. Perhaps that’s what will happen with the availability of this alternative to braided shielding.

Have you ever found the realities of standard braided shielding to be inadequate for your project, or that it imposed too many burdens? Did you look for alternative cable-shielding solutions? Was your search successful?

Bill Schweber is a degreed senior EE who has written three textbooks, hundreds of technical articles, opinion columns, and product features. Prior to becoming an author and editor, he spent his entire hands-on career on the analog side by working on power supplies, sensors, signal conditioning, and wired and wireless communication links. His work experience includes many years at Analog Devices in applications and marketing.

Related Content

• Sophisticated Cables: Not Just for RF
• Litz Wire & Other Component Cleverness
• Cable self-heating: The other side of IR drop
• Cable Assemblies: Ignore Them and Be Sorry
• Read this and give electric insulation a second thought
• Transmission line design: Why not 75 ohms instead of 50 ohms?

The post A viable alternative to braided shielded cable appeared first on EDN.

silk reel reads a .kicad_pcb file and makes a film from the real board. The film uses your copper, pads, vias, solder mask, silkscreen and part values. Nobody models or animates anything by hand. In the Trace look, the film starts with a flat plan of the board. The copper routes come out from the main chip. Then the camera tilts, and the solder mask and the silkscreen go on. Each part drops onto its paste, and the solder reflows. Last, the board powers on, and each LED lights in the colour from its part value. The film is 12 seconds long and has sound. In the Glyph look, each part of the board appears as type, in a loop. To try it with your own board, open https://silkreel.hridya.tech/studio in your browser. The page reads the file in the tab and does not upload it. For the full film, use the CLI. It makes MP4, GIF, WebM or ProRes files, in 4:5, 1:1, 9:16 or 16:9. The WebM and ProRes files have a transparent background, so you can put the film over your own footage. silk reel is fully open source: https://github.com/hridaya423/silkreel. If silk reel fails on your board, please open a issue! submitted by /u/Puzzled-Stick9170 [link] [comments]

SemiQ Inc of Lake Forest, CA, USA — which designs, develops and manufactures custom silicon carbide (SiC) power semiconductors and 150mm SiC epitaxial wafers for high-voltage applications — has announced the availability of its fourth-generation QSiC silicon carbide power devices, launching a family of 1200V and 750V SiC bare dies and MOSFETs...

Efficient Power Conversion Corp (EPC) of El Segundo, CA, USA — which makes enhancement-mode gallium nitride on silicon (eGaN) power field-effect transistors (FETs) and integrated circuits for power management applications — has announced the availability of the EPC91124 and EPC91125, two new 100V three-phase brushless DC (BLDC) motor drive evaluation boards designed to simplify the development of next-generation high-performance motion-control systems...

We put on a massive Haunted Circus every year for Halloween, so I built an ESP32-based controller to manage the increasingly insane amount of games, props, and custom lighting audio that makes it all happen. It can: Use up to 4 motion sensors and other GPIO based devices. I find Ultrasonic Sensors actually work pretty darn well in a haunt. Trigger up to 4 of pretty much any typical Spirit Halloween, Home Depot, etc prop that has a step pad or try me button. Play custom audio, including a beefy amp and lineout for powered speakers Sync jaw motion with overridden of props (with an extra MOSFET hooked up) Has two higher powered and very protected 5V PWM connectors specifically to make it easy to connect programmable RGB LED strings, servos, etc. Has a wireless interface via a hub, so I can monitor everything plus adjust motion range/sensitivity, volume, and other per-prop settings. It's fun to monitor activations from my phone. Can be powered with 5.9V-12V barrel jack adapters. And has a fused pass thru VOut so you can plug in the controller and one prop through the same adapter, very common use case to spiffy up a prop with custom audio, lights, etc. All of this is programmable via ESP32-S3-WROOM-1-N16R8 Having the extra storage is key for all the audio (and there's an even bigger module, but it was out stock at the manufacturer) The fortune teller in the second photo is a great example of the controller being used to its fullest. The attendant presses a remote control button to start the sequence. This wakes her up, and she does her movements while playing custom audio synced with her jaw synced to it. Plus extra props on the table go off. Plus it sets off a relay to create a lightning effect. Plus it tells a Pi to display a number in the crystal ball via a pepper's ghost effect. I had built a much simpler controller last year, and while I love that thing, I really wanted to push myself to actually have proper power regulation (instead of a USB brick), power protection, my own built-in amp instead of DFPlayer, etc. And it needed to get done in time for Halloween, so I put my mind to figuring out how to get AI to help the process. Over two months I ended up using GPT Sol 5.6 and later GPT Astra via Codex going pretty much every step of the PCB design process: Speccing out the functionality Initial design and component selection Sourcing datasheets, footprints, and 3D files Interpreting datasheets (so many datasheets) Iterating on and validating the design Building schematics in KiCad Some help with component placement (I did most of it, in hindsight I probably didn't need to) And the craziest thing, 99.9% of this PCB was routed by GPT Astra. There was a lot involved in getting it to work well enough, particularly anything in visual layout. The general process was to have AI attempt to do the work, figure out where it's struggling and critique it, iterate, and once we had a good workflow, have AI build a skill so it can do the rest of the step on its own. This was critical to getting good results, including having schematics and routing not look like a dog's breakfast. submitted by /u/bacontreatz [link] [comments]

Inductor-inductor-capacitor (LLC) applications that don’t require a closed control loop can benefit from simple and low-cost implementations.

High-power applications that require isolation and prioritize high efficiency often use inductor-inductor-capacitor (LLC) converters in either a half- or full-bridge configuration implemented on the primary side, depending on the voltages and power levels. Synchronous rectification is often mandatory to achieve good efficiency, especially with low output voltages.

When looking for closed-loop LLC controllers, there are various options on the market, which offer features for protection and a precise ±3% regulated output. For open-loop applications that can tolerate an unregulated output of ±10%, many closed-loop controller features aren’t necessary, and it often takes some effort to disable certain functions to get an open-loop design working.

LLC controller features

The feature set for an open-loop LLC controller can be divided into mandatory and optional features. Mandatory features include soft start, enable input, over-current protection (OCP) with cycle-by-cycle current limiting (hiccup mode or latch-off), and driving the primary-side power stage. Optional features may include power-good output, over- and under-voltage lockout, and driving the synchronous rectifiers.

The Texas Instruments programmable logic device (TPLD) family can implement these features to achieve a cost-effective solution for open-loop applications. Figure 1 is a block diagram of the TPLD2001-Q1. This device includes various logic blocks, internal oscillators with a clock frequency up to 25MHz, a state machine, and analog comparators, making it a good match for the features that an open-loop LLC controller requires.

Figure 1 This block diagram shows the building blocks available in the TPLD2001-Q1. Source: Texas Instruments

Open-loop LLC implementation

Generating control signals for the power stages is a simple task. For low switching frequencies, designers can use the internal pulse-width modulation (PWM) generators, but higher frequencies require a logic-based approach. One possible implementation is a classical ring buffer built from configurable one-shot blocks, which generate two inverted signals for the primary side and add dead time. Figure 2 shows an implementation that generates the two control signals for the primary side as well as two control signals for driving the synchronous rectifiers on the secondary side, with adjustable dead bands between primary and secondary.

Figure 2 This example implementation generates four output signals with an adjustable dead band, all within a single TPLD2001-Q1. Source: Texas Instruments

In this way, there is no need for a specialized synchronous rectifier controller. To enable synchronous rectification, a comparator channel can measure the primary-side current to enable synchronous rectification as soon as the converter input current rises above a decision threshold.

Figure 3 shows a design example using synchronous rectification without a specialized controller. The use of LMG2104-Q1 integrated half bridges simplifies the TPLD implementation, since these devices take care of the required dead time for the primary side by themselves.

Figure 3 This overview of an example design uses TI’s TPLD2001-Q1 as a controller. Source: Texas Instruments

It is possible to achieve OCP using the internal comparators, which disable switching if the primary-side current gets too large. The amount of available logic gates enables an implementation that does cycle-by-cycle current limiting by skipping cycles if the primary-side current reaches a set limit (Figure 4). After a certain period of time, the control logic then enters hiccup mode or latch-off, which either one-shots or one of the TPLD’s counters can easily implement. Also, during soft start, the disabled synchronous rectification ensures that no unwanted current flows from the output back to the input of the converter.

Figure 4 This example current-limit implementation also fits within the TPLD2001-Q1. Source: Texas Instruments

An enable input completes the connectivity requirements and resets the device so that it goes through soft start when enabled. For devices with several analog inputs, it is easy to add under-voltage lockout and over-temperature protection features.

Of course, there are some limitations to these programmable logic devices, although many are easy to overcome. When using the internal PWM generators, the maximum frequency is limited to <100 kHz because of the fixed-period counter value.

Because the open-loop LLC topology requires no duty cycle or frequency variation, you can build your own control signal generator using the available logic cells within the TPLD2001-Q1 to achieve your desired output frequency. A 25 MHz clock frequency is high enough to generate suitable dead times and output signal frequencies up to about 500 kHz. Higher frequencies are possible; however, the dead time becomes an increasing percentage of the total switching cycle, thereby lowering efficiency.

When using synchronous rectifier controllers and integrated power stages – which take care of the dead time by themselves – this efficiency penalty is no longer an issue. Figure 5 shows the switching waveform of the design example, using a TPLD for controlling the primary side and synchronous rectification.

Figure 5 This graph from the design example shows the switch node and current waveform. Source: Texas Instruments

If you don’t need more than two analog inputs, a smaller device such as the TPLD1202-Q1 is an option. But since that device has only one comparator, the inputs are multiplexed and therefore too slow for OCP. The discrete analog comparators available within the TPLD2001-Q1 are fast enough to implement OCP and can be used for other features like the previously described simple synchronous rectification control. If OCP is the only analog feature that you require, the smaller TPLD1202-Q1 device variant may be a good fit for more cost-sensitive applications.

Conclusion

The TPLD family offers enough flexibility to implement relatively complex control mechanisms for power converters. LLC applications that don’t require a closed control loop can benefit from a simple and low-cost implementation. Although this power tip is based on a working solution, depending on the overall requirements (for example, bidirectional operation or higher switching frequencies), some device limitations could demand a different approach. Here, the TI MSPM0 microcontroller could become a valid option.

As part of the Power Design Services team, Björn Görner has eight years of experience designing custom power solutions and reference designs, with the main focus on automotive applications. He is a regular presenter for Power Supply Design Seminars, which Texas Instruments offers biannually to educate and support anyone interested in power conversion.

 

Related Content

• Power Tips #155: How to choose the best topology for isolated energy storage systems
• How to design a digital-controlled PFC, Part 4

The post Power Tips #158: Using a programmable logic device as an LLC controller appeared first on EDN.

India’s growing real estate sector and investments in power transmission, renewable energy, industries and infrastructure are increasing demand for copper, electrical conductors, wires and cables. According to ICRA, India’s wires and cables industry was projected to grow by 12–14% annually, reaching ₹1.2 lakh crore by FY2027. Copper and other conductive materials are key raw materials used to manufacture products for buildings, power networks and industrial applications. Companies across this value chain handle different stages of production, from copper processing to manufacturing finished wires and cables for various electrical needs.

KEI Industries Limited manufactures wires and cables for homes, commercial buildings, industries and infrastructure projects. Its products include house wires, PVC-insulated cables, low- and high-voltage power cables, extra-high-voltage cables, control and instrumentation cables, and speciality cables. These products are used in sectors such as power generation and distribution, real estate, railways, renewable energy and industrial manufacturing.

Headquartered in Bengaluru, Gopalan Metals is a copper-manufacturing company backed by the Gopalan Group’s four-decade legacy. The company manufactures copper products, including rods, wires, busbars and strips, catering to applications across the electrical, industrial and infrastructure sectors. It has also expanded into the building-wires segment, offering FR and FRLS-H PVC house wires made using electrolytic copper conductors. Manufactured at its Hoskote facility in Bengaluru, these products cater to residential, commercial and industrial applications. With a monthly production capacity of approximately 6,000 km of building wires and BIS certification, the company serves dealers, distributors, contractors, builders, OEMs and institutional customers.

Gujarat Copper Alloys manufactures a range of copper and copper-alloy products, including busbars, rods, flats, strips, foils, profiles, sections and tubes. These products serve applications across electrical equipment, power infrastructure and industrial manufacturing. Its portfolio includes copper materials used in the fabrication of components for electrical and industrial systems, linking copper processing with downstream infrastructure and manufacturing requirements.

RR Kabel is an electrical products manufacturer with a portfolio spanning wires and cables, switches, fans, lighting, switchgear and appliances. Its wires and cables are designed for residential, commercial, industrial and infrastructure applications. The company focuses on product quality, safety and engineering, with a range of electrical solutions developed to meet diverse installation requirements. Its presence across multiple electrical product categories enables it to serve both building-related requirements and broader industrial and infrastructure needs.

Supporting India’s electrical and infrastructure needs

The post Powering India’s Growth: Key Companies in the Electrical Infrastructure Value Chain appeared first on ELE Times.

At electronica 2026 in Munich, Rohde & Schwarz will showcase a range of test and measurement solutions for everyday engineering tasks and complex testing requirements. At booth A4.307, visitors can see demonstrations of technologies used for satellite and radar testing, electronics and RF design, power electronics testing, electromagnetic compatibility (EMC) testing, quantum research and electronics production.

From November 10 to 13, 2026, Rohde & Schwarz will showcase its test and measurement solutions at electronica 2026 in Munich under the theme “From the everyday to the extraordinary.” At booth 307 in Hall A4, the company will demonstrate equipment for routine engineering tasks as well as specialised testing applications. The demonstrations are aimed at developers, electronics engineers and test specialists.

Highlights – from the everyday to the extraordinary

Rohde & Schwarz will introduce a new handheld analyzer that combines spectrum analysis, real-time spectrum analysis (RTSA), vector network analysis (VNA) and power measurements in one portable device for field testing. The company will also unveil the R&S HMP5050, a new DC power supply with up to five independent channels, designed to support a range of electronics testing and laboratory tasks.

For rather extraordinary applications, visitors will be able to see the FSWX signal and spectrum analyzer with its game-changing multi-channel capabilities, high sensitivity and wide dynamic range, designed by Rohde & Schwarz engineers to overcome the constraints of traditional measurement methods. Furthermore, the company’s displays will address a broad range of testing challenges across different applications and industries.

Aerospace and satellite testing

In aerospace and satellite testing, Rohde & Schwarz will present a testbed for low Earth orbit satellite links and phased array beam steering, using a robotic arm to emulate satellite movement. Visitors will also be able to see 5G non-terrestrial network (NR-NTN) testing with the CMX500 one-box signalling tester. Another focus is micro-Doppler simulation for drone detection in 6G ISAC with the AREG800A automotive radar echo generator.

Electronics and power electronics testing

In electronics and power electronics testing, the company will show solutions that support engineers from early design work to validation. These include electric drivetrain efficiency measurements with the LMG600 Series power analyser from ZES Zimmer, 3-phase power analysis with MXO oscilloscopes, and current transient measurements on wide-bandgap devices using the MXO 5 oscilloscope and the R&S RT-ZISO isolated probing system. Another setup shows how multiple oscilloscopes can be synchronized to support measurements with up to 24 channels using the ScopeSync App. The demonstration will also highlight MXO AI Connect, which enables compatible AI agents to access MXO knowledge, control the oscilloscope, and support measurement workflows using natural language.

For validation tasks, Rohde & Schwarz will also present signal and power integrity measurements for high-speed designs, including SerDes applications, using the R&S RTP oscilloscope and SEPIA by Picotest from Signal Edge Solutions. High-speed digital interface testing up to 54 GHz with the R&S ZNB3000 vector network analyser will also be part of the display.

RF and microwave testing

Addressing RF and microwave applications in particular, Rohde & Schwarz will present phase noise measurements up to 170 GHz with the R&S FSWP phase noise analyser and frequency extensions. The booth will also feature two-port amplifier testing with wideband modulated signals using the FSWX signal and spectrum analyser and its two-channel architecture. High-power Ka-band amplifier characterization with the R&S ZNA vector network analyser in combination with the new R&S SAM200 system amplifier in a fully integrated and calibrated test setup will also be on display. In addition, visitors can learn about interference testing for automotive radar validation with the AREG800A automotive radar echo generator.

EMC compliance testing

Further demonstrations will focus on conducted and radiated EMI measurement with an emphasis on speed, automation and flexibility. Rohde & Schwarz will show ultrafast compliance testing with the R&S ESW EMI test receiver and automated EMC testing with R&S ELEKTRA software. The R&S EPL1007 EMI test receiver offers users the flexibility to upgrade with evolving needs. Customized RF and EMC test systems for complex environments will also be part of the presentation.

Quantum research

In quantum research, Zurich Instruments will present solutions for quantum computing, quantum sensing, and sensor control. Demonstrations will include quantum computing control systems that scale from a single qubit to 1000 qubits (SHFQC and ZQCS), arbitrary waveform generation for quantum technologies (HDAWG) and sensor characterization with impedance analyzers (MFIA) and lock-in amplifiers (VHFLI and SHFLI).

Production, manufacturing and service

The production and manufacturing section will cover end-of-line testing of power electronics modules in line with standards such as AQG 324 with PE-Systems employing the MXO 5C oscilloscope, as well as manufacturing test of telematics control units and wireless battery management systems with the R&S ExpressTSVP test platform and CMP180 radio communication test set.

Furthermore, Rohde & Schwarz will present its electronic manufacturing services (EMS), ranging from prototype builds to serial production. And trade show visitors can learn about the Rohde & Schwarz Service portfolio, including on site calibration, depot services, calibration and repair options, warranty extensions and other service offerings.

The post Rohde & Schwarz to Showcase Advanced Test and Measurement Solutions at electronica 2026 appeared first on ELE Times.

Infineon Technologies AG of Munich, Germany is establishing the world’s first high-volume manufacturing facility for gallium nitride (GaN) power semiconductors on 300mm wafers in Europe. As part of the project, the firm will invest about €1.1bn in its existing cleanroom facilities at the site in Villach, Austria by 2034. Leveraging both the existing and upgraded infrastructure will enable efficient and cost-effective expansion of manufacturing capacity, it is reckoned. Production is scheduled to start by the end of 2027...

Cadence has introduced its Maestro AI Model Portfolio to support its AI Super Agents in semiconductor and system design. The portfolio combines specialised AI models with reinforcement learning and Cadence’s existing electronic design automation (EDA) and system design automation (SDA) tools. This integrated platform aims to improve design quality, speed up engineering workflows, reduce development time and continuously improve performance based on feedback from previous tasks.

Cadence Maestro provides a secure AI platform that helps engineers handle complex chip and system design tasks. It combines specialised AI models of different sizes with trained decision-making systems and AI skills that improve through repeated use and feedback. The platform works with Cadence’s AI Super Agents, including AuraStack, ChipStack, InnoStack and ViraStack, along with its existing electronic design automation (EDA) and system design automation (SDA) tools. It can also combine Cadence’s specialised models with other advanced and open-weight AI models. Customers can deploy these capabilities through cloud services or on-premises systems, giving them greater flexibility and control over their engineering data and design workflows.

“Revolutionizing complex engineering tasks requires deep domain-specialized intelligence,” said Anirudh Devgan, president and CEO at Cadence. “Combining our Maestro portfolio of domain-specialized models with leading frontier and open-weight models enables our AI Super Agents to drive Cadence EDA and SDA tools with exceptional skill and efficiency to transform chip and system design.”

“Agentic chip design requires AI that can generate design content, evaluate tradeoffs and learn from verified engineering results,” said Tim Costa, vice president and general manager of industrial and computational engineering at NVIDIA. “Our collaboration with Cadence brings NVIDIA Nemotron, OpenShell and deep engineering expertise to Maestro’s domain-specialized models. By grounding reinforcement learning in feedback from EDA tools and deterministic solvers, we can teach agents to make better design decisions based on how well their work meets engineering objectives and constraints.”

“We are deploying Cadence’s InnoStack AI Super Agent into our production design environment,” said Hisato Yoshida, COO of Socionext. “By combining agentic AI with advanced EDA tools for physical design, we expect up to 5X overall productivity gains while maintaining design quality. We see the Maestro portfolio as the next step in driving even greater efficiency across our design process.”

“Ultra-low power devices require innovation across disciplines. Agentic AI unlocks new power opportunities,” said Garima Sharda, vice president of engineering at Silicon Labs. “By leveraging the Cadence Verisium Debug as part of ChipStack AI Super Agent, our engineering teams have achieved acceleration in root-cause analysis and end-to-end debug during pre-silicon low power verification. We look forward to realizing further benefits through Cadence’s Maestro domain-specialized models.”

A Self-Improving Learning Environment for Engineering AI

Initial results show up to 30% improvement in quality of results and up to 5X greater token efficiency versus general purpose foundation models. These gains come from a vertically integrated learning environment combining Cadence domain knowledge, curated engineering datasets, AI Super Agents, EDA and SDA tools, and evaluation harnesses. Cadence’s principled algorithms and deterministic solvers evaluate outputs against engineering objectives, constraints and ground truth, creating closed and verified feedback loops for reinforcement learning and recursive improvement.

Domain Intelligence with Intelligent Model Choice

The Cadence learning environment unifies complementary AI capabilities in a single workflow. Frontier and open-weight models provide broad language, reasoning and multimodal capabilities; the Maestro AI Model Portfolio provides domain expertise for complex chip and system design. Given a high-level objective, Cadence AI Super Agents interpret design intent, decompose tasks, orchestrate the Maestro portfolio with other leading frontier and open-weight models, and drive Cadence EDA and SDA tools. The combined solution interprets specifications, generates design content, analyzes results, evaluates tradeoffs and guides decisions based on engineering requirements, cost and security. The Maestro portfolio, including NVIDIA Nemotron and other models, can be further post-trained on a customer’s proprietary data, designs, and workflows and, by balancing EDA and SDA tool calls with LLM invocations, it significantly reduces token usage while maintaining execution efficiency.

The complete Cadence agentic environment—including AI Super Agents, Maestro AI Model Portfolio and EDA tools—can run on Cadence’s secure cloud platform, secure public clouds, or in a customer-controlled on-premises environment to meet data privacy, security and deployment requirements. Cadence and NVIDIA are also working together on agent security through integration with the NVIDIA OpenShell Reference Architecture.

The post Cadence Introduces Maestro AI Models to Accelerate Chip Design With Up to 5X Greater Token Efficiency appeared first on ELE Times.

Abhishek Pandey ELE Times, Sub-Editor

Inside the architecture, platforms and security controls help enterprises coordinate AI agents, automate complex workflows, and move autonomous AI from experimentation into production.

The Importance of Orchestration: Issues Beyond Individual AI Agents

AI (Artificial Intelligence) will advance from a chatbot answering queries to one that can plan how to execute tasks, perform the jobs that software tools do, discover information, and run multi-stage workflows. The AI agents are capable of doing useful things with some oversight. But in a business workflow running across multiple systems, a specialised task or an approval stage requires more than a single agent.

Enter AI agent orchestration. Orchestration is how you ‘align the agents, the model, your tools, data sources, and workflows’ so they accomplish your objective. Orchestration gives your system the ability to pass, control dependencies, maintain context, recover from failure and know when to call a human. That’s because building an agent makes it do the task; orchestrating it makes it part of a trusted end-to-end business process.

Inside the Architecture: How AI Agent Orchestration Works

Most orchestration systems consist of multiple interacting parts. The orchestrator “knows the objective, formulates or takes a sequence of steps, delegates work, and tracks results.” One or more agents execute the specific tasks in fields like research, data extraction, processing, document generation, or software operation.

It consists of a model layer for reasoning and language generation, a memory layer for storing relevant context, and a tools layer for enabling agents to interact with business applications and external systems. Monitoring and policy controls can keep actions within boundaries.

The flow could be a straightforward linear series of steps where one agent’s final result drives the next, or more flexible with the orchestrator determining the next steps based on intermediate results. Intelligent automation could retry a step if the output is validated, or bring in a human to take over if uncertain or risky.

The description Google Cloud gave of its Gemini agent shows this shift in focus. Here’s how Thomas Kurian, President and CEO, Google Cloud, explained, “You give it objectives, not instructions. You delegate an outcome and come back to finished work.”

This principle is key to orchestrating agents: instead of explicitly ordering all actions, people can ask an agent to do a task by defining an objective, and the agent will prepare the work, choose its tools, and organise the necessary actions to achieve it. Full autonomy remains a matter of available tech and permissions.

The Framework Race: Platforms Powering Enterprise AI Agents

When it comes to libraries, frameworks offer developers reusable parts to help construct and coordinate agents. These include support for defining workflows, tool calling, state management, agent communications, and integrations with external services.

LandGraph supports stateful, graph-based workflows. They can control the flow of execution and structure more complex workflows. The goal of the OpenAI Agents SDK is to enable developers to access the primitives necessary for high-level agent commands, tools, handoffs, and guardrails. The ADK from Google supports creation and orchestration of agents, while CrewAI abstracts the orchestration of agents and tasks into collaborative workflows. Llamalndex workflows, developers can create multi-step, event-driven applications that are event driven that have data and retrieve.

However, these two options are not necessarily always exactly the same. It may be a hard decision to make because it really depends on how you work and observe the setting where you will use it. Comparing the solutions for real workloads is the key. A framework does not also mean an enterprise is fully governed. There may also be a need for additional platform services or custom development for identity management, access control, audit logging, monitoring, and approval processes.

From Context to Continuity: How AI Agent Memory Works

Memory allows an agent to utilise information other than the provided prompt. An agent with no memory would need to be prompted to recall the same information each time or may forget key details along the way.

Short-term or working memory keeps information available during the current task. Long-term memory stores information for use over a series of sessions. Semantic memory encodes information (Facts and concepts); episodic memory documents relevant episodes or events. Some systems may additionally require storing reusable procedures/skills in procedural memory.

Memory must be carefully controlled. Too little information can reduce consistency, and excess will either make the system costlier, give the user information they do not require, or in some instances, reveal confidential information. Businesses need to have a policy in place regarding what is stored, for how long, and who accesses it and when.

Memory also should not be mistaken for model training. An agent can make use of its memory at runtime without modifying the existing model parameters. The right orchestration of memory, retrieval, permission, and context selection enables an agent to provide the right information for every task.

Connecting AI to the Real World: Tools, APIs and MCP

An agent becomes more valuable when enabled to integrate with systems outside its language model. Tools and APIs allow your agents to view records, perform database searches, update tickets, produce reports, and perform supported business actions.

Model Context Protocol (MCP) is an open protocol for describing how an AI app connects to external tools and context providers. MCP servers can expose tools, resources, and other functionality to MCP clients, helping users discover and reuse those integrations in an orchestration fashion.

Connectivity isn’t the same as authorisation. Just because you’ve given an agent the access it requires to do its job, it shouldn’t be making further decision-altering production data changes, approving payments, or sharing sensitive information-which will need further verification or human approval.

Additionally, organisations need to monitor the tools’ production, test inputs, trap bugs, and secure secrets. A successful API call does not mean that you made the right call or that the response is valid.

Single Agent or Multi-Agent System? Choosing the Right Approach

A single agent architecture is often appropriate when a task has a specific goal, few interdependencies, and a simple ordering of actions. It is typically more straightforward to test, monitor, and service.

A multi-agent system might be appropriate if the work is most naturally divided among specialists. For instance, a research agent might collect data, an analysis agent might examine the data, and a reporting agent might compile the final document. The orchestrator manages the handoffs and verifies if the combined result satisfied the criteria.

Though, the introduction of agents towards the system costs us some communication overhead, more model calls, inconsistencies, more difficult failure handling, and harder-to-debug systems. A multi-agent system could become costlier and more complicated to work with than a simpler system.

The moral of the story is not to over-architect. For most projects, start with the least complicated architecture that will do the work. Use specialised agents only where they provide a measurable increase in accuracy, scale, or performance.

Keeping Autonomous AI Under Control: Governance, Security and Observability

Enterprise orchestration should, therefore, not just accomplish a task. It should be used to decide who should do what, and on which resources. Ensure all tasks that should be done are done, that what should have been done is present, what was done, and how to verify or undo what was done.

Add: Least privilege permissions, runtime enforcement of policy, protected runtime environment audit and monitoring, and human approval gates. Observability might be even more important, as the failure can happen in different agents, tools, and systems rather than in a single model response.

ServiceNow announced with NVIDIA in October this year, identifying this as a problem. Jon Sigler, Executive Vice President and General Manager of AI Platform at ServiceNow, explained, “As AI agents take on more autonomous tasks, governance and security have to extend to everything they touch.”

ServiceNow Arc is generally available under the governance of the ServiceNow Super Intelligence Control Tower and the enforcement of the NVIDIA Open Shell. Further, it discusses the intended future integration of AI Passport with NVIDIA Open Shell and NVIDIA Blue Field enforcement layers. These supposed future features should not be described as generally available.

Airing similar views, Justin Boitano, Vice President of Enterprise at NVIDIA, said, “Enterprises are using AI agents to do real work, and that means policy has to be enforced everywhere an agent runs.”

Boitano’s point is that governance must live in the execution environment where the agents operate, not in some high level policy or, worse, an application-level configuration setting. Runtime enforcement can limit an agent’s access to systems and tools, even while it carries out its multi-step work.

From Experiments to Enterprise Deployment: The Challenges Ahead

When an orchestrator makes the leap from demo to production, it will need testing. This is because single agents might get inconsistent results, misinterpret directions, pick the wrong tool, or just fail if the service, they’re attached to is unavailable. Multi-agent systems magnify these problems when one agent passes on an invalid output.

Organisations should measure the rate of task completion, quality of output, latency, cost of operation, tool-call accuracy, and policy adherence. They should additionally check failure recovery, access limits, and the ability to withstand malicious instructions included in external content.

Cost management is also an issue. A workflow that fires off many large models, transmits too much context, or offloads too many subtask requests can rack up high costs. Model routing, caching, bounded retries, and well-defined stopping conditions can all improve things.

Begin by deploying use cases, defined success metrics, and permissions within your controls. As this technology matures and grows more reliable, however, an agent’s capabilities can increase while remaining under suitable human supervision.

What Comes Next? The Future of AI Agent Orchestration

AI agent orchestration is moving into more persistent agents, reusable skills, enhanced memory, standardised integrations, and tighter runtime controls. On the enterprise side, agent discovery, centralised monitoring, and policy enforcement are also becoming key focus areas.

The real goal is not to keep adding more agents, but to make the agents coordinate reliably across processes, and in a manner that is intelligent, auditable, and limited.

Business-wise, bringing that orchestration to bear will mean balancing the degree of system autonomy with the degree of system control. An information system equipped with a certain amount of autonomy and system control. An information system that combines smart planning, serviceable memory, strong tools, measurable delivery, and deployable controls is more likely to clear the pilot hurdles and create value.

The post AI Agent Orchestration Explained: How Frameworks, Memory, Tools and Governance Work Together appeared first on ELE Times.