About Us

Who we are

FRESCOR is an independent knowledge resource dedicated to real-time embedded systems: the software and hardware that must not only produce the right result, but produce it at the right time. The site was relaunched in 2026 on the frescor.org domain and is operated by FRESCOR.org. Our focus covers scheduling theory, contract-based and flexible scheduling, timing and worst-case execution time (WCET) analysis, real-time operating systems, embedded architectures, real-time networking, and the safety standards that shape how timing-critical systems are built and certified.

The name FRESCOR stands for “Framework for Real-time Embedded Systems based on COntRacts.” It was originally the name of a European research project that ran from 2006 to 2009. When the domain became available, we chose to relaunch it as an independent, practitioner-oriented site that keeps a respectful, factual record of that project while building something new around the same core ideas: predictable timing, composable software, and making efficient use of constrained hardware.

We write for embedded software engineers, firmware developers, systems architects, students and researchers, and the technical managers who have to make platform and tooling decisions. Some readers arrive with a specific problem, such as a missed deadline on a motor controller or an unexplained latency spike on a Linux gateway. Others want a structured way into a field whose literature can feel scattered and intimidating. We aim to serve both.

Our mission

Our mission is to make real-time and embedded timing knowledge practical and accessible. Real-time systems theory is mature and well founded. Results such as the Liu and Layland utilization bound, response-time analysis, the priority ceiling protocol and constant bandwidth servers have been refined over decades. Yet in day-to-day engineering, these ideas are often applied informally, partially or not at all. Teams frequently rely on testing alone, generous hardware margins, or rules of thumb whose assumptions nobody has checked.

We think the gap between theory and practice is mostly a communication problem. Many excellent results live in academic papers, conference proceedings and textbooks written for specialists. We try to bridge that gap by:

• Explaining concepts in clear language, with worked examples and the assumptions stated explicitly.
• Connecting analysis techniques to the platforms engineers actually use, such as Zephyr, FreeRTOS, NuttX, RTEMS and PREEMPT_RT Linux.
• Providing tools that let readers experiment with schedulability questions directly instead of only reading about them.
• Being honest about limitations, including where a technique is pessimistic, where it does not apply, and where the state of the art is still evolving.

A good starting point is our introduction, What Is a Real-Time Embedded System?, which explains hard, firm and soft deadlines and sets out the vocabulary used throughout the site.

The FRESCOR legacy

The original FRESCOR project was a collaborative research project funded under the European Union’s Sixth Framework Programme (FP6), in the Information Society Technologies (IST) area, under contract FP6/2005/IST/5-034026. It ran from 2006 to 2009 and was coordinated by the Universidad de Cantabria in Spain.

What the project set out to do

The central goal of the project was to integrate contract-based flexible scheduling into component-based design for embedded systems. In this approach, each application component states its timing and resource requirements as a contract: for example, a minimum budget of processor time per period, a deadline, and the range of resources it can make good use of if more becomes available. A scheduling framework then checks whether a set of contracts can be guaranteed together, reserves the resources needed, and redistributes spare capacity among components according to their importance and quality-of-service preferences.

The appeal of this model is composability. Components can be developed, analyzed and validated independently, then combined on a shared platform with predictable timing, because each one is isolated from the others by its reserved budget. The project worked on extending these ideas beyond the processor to other resources such as networks, memory and energy, and on making them usable from a design methodology rather than only from low-level scheduling code. To learn more about the underlying concepts, read Contract-Based Scheduling Explained and SCHED_DEADLINE and the Constant Bandwidth Server.

The consortium

The project brought together 11 partners from universities, research institutes and industry:

• Universidad de Cantabria (coordinator)
• University of York
• Scuola Superiore Sant’Anna
• TU Kaiserslautern
• Universidad Politécnica de Valencia
• Czech Technical University in Prague
• ENEA
• Thales
• Visual Tools S.A.
• Rapita Systems Ltd
• Evidence

Evaluation domains

The project’s results were intended to be evaluated in demanding, realistic application domains where flexible use of resources matters:

• Multimedia phone video streaming, where decoding and display must keep pace with incoming data on resource-constrained devices.
• Software-defined radio, where signal-processing chains have tight timing constraints and must share processing resources.
• Digital video surveillance, where multiple video streams must be captured, processed and recorded with predictable quality.

Our archive pages summarize the historical project in more detail: the project overview, the objectives, the expected results and the list of partners. Related links and conference material are collected under links and documents and conferences.

What we publish

Our content falls into three broad groups.

In-depth articles

Our articles are long-form explanations of a single topic, written to be read start to finish or used as a reference. Each one opens with key takeaways, states its assumptions, includes worked examples where they help, and ends with references to stable, authoritative sources. Topics include:

• Scheduling theory, such as Rate Monotonic vs Earliest Deadline First and Response-Time Analysis: A Step-by-Step Worked Example.
• Timing analysis, such as WCET analysis methods and priority inversion and the priority ceiling protocol.
• Platforms and architectures, such as choosing an RTOS in 2026, multicore real-time scheduling and real-time networking with CAN and TSN.
• Applications and design methods, such as mixed-criticality systems, timing in UAV flight control and model-based design with Simulink and AADL.

The full list is on the blog.

Interactive tools

The schedulability calculator lets you enter a periodic task set and check it under rate monotonic and earliest deadline first scheduling. It computes total utilization, compares it with the relevant bounds, runs exact response-time analysis for fixed priorities and draws a Gantt chart of the resulting schedule. It is designed for learning and quick sanity checks, not as a substitute for a qualified analysis of a production system.

Reference material

Our glossary defines the core vocabulary of the field, from jitter and hyperperiod to mixed criticality and time-sensitive networking, with links to the articles that cover each term in depth. The FAQ answers common questions about the site and about real-time concepts.

What we offer

Alongside the free content, FRESCOR.org offers a small number of professional services and digital products for teams that want hands-on help. These include schedulability audits, RTOS selection and migration consulting, WCET and timing analysis, real-time Linux tuning with PREEMPT_RT and SCHED_DEADLINE, a training workshop on contract-based scheduling, and a downloadable field guide. Each offering is described on the services page with its scope, deliverables and typical timeline, and the final scope of any engagement is confirmed in writing before work begins.

Our services are kept clearly separate from our editorial content. We do not write articles to promote a service, and an article’s conclusions never depend on whether we sell something related to it.

Editorial principles

Trust is the foundation of a technical reference. Our approach is described in full in our editorial policy, but in short:

• Accuracy first. We check technical claims against primary sources such as textbooks, standards, official documentation and peer-reviewed literature, and we cite them.
• No invented evidence. We do not fabricate statistics, studies, quotes, case studies or testimonials. If we are unsure about something, we say so.
• Stated assumptions. Schedulability results depend on their models. We state the task model, scheduling policy and platform assumptions behind every analysis we present.
• Vendor neutrality. We compare operating systems, tools and hardware on their technical merits. We do not accept payment for coverage.
• Corrections. When we get something wrong, we fix it and update the “last updated” date. Readers are encouraged to report errors.

Images used on the site are credited on the image credits page, and general limitations of our content are explained in the disclaimer.

Timeline

1. 2006 — The FRESCOR research project begins under the EU Sixth Framework Programme, coordinated by the Universidad de Cantabria.
2. October 2006 — The project holds a requirements workshop in Madrid to gather application and platform needs.
3. November 2006 — The project is presented at the IST 2006 event in Helsinki.
4. 2009 — The FRESCOR project concludes.
5. 2026 — frescor.org is relaunched as an independent knowledge resource on real-time embedded systems, with an archive of the historical project.

Our values

• Predictability over guesswork. We favor analysis that gives guarantees, and we are clear about when testing alone is and is not enough.
• Clarity. A correct explanation that nobody can follow helps no one. We write for understanding.
• Openness. Our articles, tools and glossary are freely available, and we point readers to open-source platforms and public standards wherever possible.
• Humility. Real-time systems are hard. We acknowledge open problems, competing approaches and the limits of our own knowledge.
• Respect for history. We describe the original FRESCOR project and its contributors accurately and never claim their work as our own.
• Accessibility. We aim for content that works for everyone, as described in our accessibility statement.

How to contact us

We welcome questions, corrections, topic suggestions and inquiries about our services. The easiest way to reach us is through the contact page or by e-mail at support@frescor.org. Our postal address is available on request via support@frescor.org.

When reporting a technical error, please include the page address and, if possible, a reference that supports the correction. When asking about a service, a short description of your platform, operating system and timing problem helps us reply with something useful. We read every message, although we cannot always provide free individual technical support.

Thank you for visiting frescor.org. We hope you find it useful, and we look forward to hearing from you.