This Editorial Policy explains how FRESCOR.org researches, writes, reviews, corrects and updates the content published on frescor.org. We want readers to be able to trust what they read here, and to understand how it was produced. If you find something that does not meet these standards, please tell us.
Last updated: October 19, 2026
Key takeaways
- Our articles are based on primary sources: standards, peer-reviewed research and official documentation.
- Drafting tools, including AI writing assistants, may be used, but every article is reviewed and fact-checked by a human editor before it is published.
- We correct errors promptly and openly, and show when each article was last reviewed.
- Our professional services are kept separate from editorial content. We accept no paid placements.
- Texts from the original FRESCOR research project are preserved verbatim and clearly labeled as historical.
Our mission
frescor.org is an independent knowledge resource about real-time embedded systems. We cover scheduling theory, contract-based and flexible scheduling, timing analysis, real-time operating systems, multicore and mixed-criticality architectures, and real-time networking. Our aim is to explain these topics accurately and clearly, for engineers, students and technical decision-makers, without hype and without oversimplifying.
The site also preserves the archive of the original FRESCOR project (Framework for Real-time Embedded Systems based on COntRacts). This was a research project funded under the EU Sixth Framework Programme from 2006 to 2009 and coordinated by Universidad de Cantabria. Keeping that material available is part of our mission.
Independence
frescor.org is operated by FRESCOR.org. It is not operated by, affiliated with, or endorsed by the original FRESCOR consortium, any of its partner organizations, or the European Commission. Archive material is presented for historical and educational purposes. Its presence on this site does not imply endorsement of our current content or services by the original authors.
Editorial decisions, including which topics we cover, which technologies we discuss and what conclusions we reach, are made by our editors alone. No vendor, RTOS project, tool supplier or other third party can review, approve or change our articles before publication. We do not accept payment, free products or other benefits in exchange for coverage.
How we research articles
Real-time systems is a field where small errors, such as a wrong bound or a misread scheduling condition, can mislead readers. We therefore build articles on primary sources wherever possible:
- Standards and specifications, for example POSIX real-time extensions, IEEE 802.1 Time-Sensitive Networking standards, ISO 11898 (CAN), ARINC 653, ISO 26262 and DO-178C, as far as their published content allows.
- Peer-reviewed research, including foundational papers (such as Liu and Layland’s 1973 analysis of rate monotonic and deadline-driven scheduling) and later work published in recognized journals and conferences.
- Official documentation, such as the Linux kernel documentation, and the official documentation of Zephyr, FreeRTOS, Apache NuttX, RTEMS and other projects and vendors.
- Textbooks and reference works by recognized authors in the field, used to confirm definitions and widely accepted results.
Secondary sources, such as blog posts, forum threads and encyclopedia articles, may help us find primary material. However, we do not rely on them alone for technical claims. Where possible, we check formulas, worked examples and code samples ourselves, for example by recalculating results by hand or with our own schedulability calculator, or by running code on representative hardware or emulators.
We do not invent statistics, studies, quotes, case studies or testimonials. When a claim depends on context, such as an RTOS feature that varies by version or configuration, we say so and state the version or date we checked.
Technical review
Every article passes through these stages before publication:
- Outline and source collection. The scope of the article is defined and the main sources are gathered.
- Drafting. A first draft is written. Drafting tools may be used at this stage (see the next section).
- Technical review. A human editor with knowledge of the subject checks definitions, formulas, worked examples, code and technical claims against the sources.
- Fact-check of references. Every link and citation is opened and checked to confirm that it exists and supports the statement it is attached to.
- Editing for clarity and accessibility. The text is edited for plain language, logical structure, correct headings, descriptive links and accessible tables, as described in our Accessibility Statement.
- Approval and publication. The article is published only after the editor is satisfied that it is accurate and meets this policy.
Use of AI and drafting tools
We believe readers should know how content is produced. Drafting tools, including AI-based writing assistants, may be used to help with outlining, first drafts, summarizing source material, checking grammar or suggesting clearer wording.
These tools can produce errors, including invented references and confident but incorrect technical statements. We therefore apply the following rules:
- Every article is reviewed and fact-checked by a human editor before publication. No article is published automatically.
- All technical claims, formulas, examples and code are checked against primary sources or verified independently.
- Every reference is checked by a person. References that cannot be verified are removed.
- AI tools are not used to generate quotes, testimonials, reviews, personal experiences or data presented as real.
- Responsibility for published content always rests with our editors, not with any tool.
Corrections policy
We make mistakes, and we want to fix them quickly. When we learn of an error, we review it promptly. If it is confirmed, we correct it.
| Type of change | Example | How we handle it |
|---|---|---|
| Minor fix | Typo, broken link, formatting problem | Corrected without a note. |
| Correction | Wrong formula, incorrect result in a worked example, inaccurate description of a feature | Corrected, with a dated correction note at the end of the article explaining what changed. |
| Significant correction | An error that changes the main conclusion or advice of an article | Corrected, with a prominent dated note near the top of the article. Where needed, the article is substantially revised. |
How to report an error
If you believe something on frescor.org is wrong, out of date or misleading, please email support@frescor.org or use our Contact page. Helpful details include:
- The address (URL) of the page and the section concerned.
- What you believe is incorrect, and why.
- A source that supports your correction, if you have one.
We aim to acknowledge error reports within five business days, and to tell you the outcome once we have reviewed the issue.
Updates and “last reviewed” dates
Real-time and embedded technology changes. New kernel releases, RTOS versions and standards appear regularly. We review our articles periodically, and whenever we learn that a significant change affects them. Each article shows:
- the date it was first published; and
- the date it was last reviewed or updated.
A “last reviewed” date means an editor has checked the article and confirmed that it is still accurate, even if few changes were needed. Where version-specific information is involved, such as RTOS feature comparisons, we say which version or date the information refers to.
Sourcing and linking
- Articles end with a “References and further reading” list of the main sources used.
- We link to stable, authoritative sources such as standards bodies, official project documentation, the Linux kernel documentation, CORDIS and well-established reference works.
- Where a source has no stable public URL, such as some books and papers, we cite the author, title and year without a link. We do not invent links or identifiers.
- External links are chosen for their usefulness to readers. We do not use affiliate links, and we do not accept payment for links.
- Linking to an external site does not mean we endorse its content or the organization behind it.
Conflicts of interest
FRESCOR.org offers a small number of professional services and products. These include schedulability audits, RTOS selection consulting, timing analysis, real-time Linux tuning, a training workshop and a digital eBook, which are listed on our services page. We recognize that this creates a possible conflict of interest, and we manage it as follows:
- Separation. Editorial articles are written to inform, not to sell. Service and product pages are kept in a separate section of the site.
- Clear labeling. Wherever an article mentions one of our own services or products, the mention is clearly identified as our own offering.
- No paid placements. We do not publish sponsored articles, advertorials or paid reviews. No third party can pay to be included, ranked or recommended.
- Fair comparisons. When we compare technologies, such as RTOSes or scheduling approaches, our conclusions are based on technical criteria and sources. They are not influenced by any commercial relationship.
- Disclosure. If we ever have a relevant relationship with an organization or product discussed in an article, we will disclose it in that article.
Archive material
The original FRESCOR project texts, such as project overview, objectives, expected results, partner descriptions, conference listings and document lists, are an important historical record. Our policy for this material is:
- Preserved verbatim. Original project texts are kept as they were written. We do not rewrite or update their content. We may fix markup, broken formatting or accessibility problems without changing the wording.
- Clearly labeled. Archive pages, such as the project overview and partners pages, are labeled as historical material from the 2006–2009 project. Labels and introductions we add are visibly separate from the original text.
- Context added separately. Where historical information is out of date (for example, organization names, links or contact details), we add an editor’s note rather than changing the original text.
- Rights respected. If you are an original author or rights holder and have concerns about archived material, please contact us, or see our DMCA Policy.
Image policy
We only use images that we have created ourselves or that are available under an open license that permits our use, such as Creative Commons licenses or public domain dedications. We follow each license’s attribution requirements. Credits for photographs and other third-party images, including the author, source and license, are listed on our Image Credits page.
Diagrams and charts that explain technical concepts are produced by us, unless stated otherwise. We do not alter images in ways that would mislead readers about what they show. If you believe an image has been used or credited incorrectly, please let us know and we will correct or remove it.
Contact
Questions, comments and error reports about our editorial standards are welcome. Please contact FRESCOR.org at support@frescor.org, write to us at available on request via support@frescor.org, or use our Contact page. For legal information about using this site, see our Terms and Conditions and Disclaimer.