From Evaluation Licence to Production Licence: How Embedded Unit Test Tool Licensing Actually Works in India

Licensing Is a Project Decision, Not a Purchasing Detail

Most teams treat the licence as the last step: the tool is chosen on technical merit, the evaluation goes well, and someone raises a requisition assuming the rest is paperwork. It is not. The licence model decides who can run a test, whether the nightly build is allowed to run one, what happens when a laptop leaves the network, and how many engineers can work in parallel the day before a release.

In one paragraph: the path from evaluation to production holds four decisions. Get an evaluation licence tied to the right machine. Decide whether the licence key file sits on one machine or is served to the team. Size concurrent seats against measured usage, not headcount. Licence your automation separately from your engineers. For TESSY all four run through the Floating License Server (FLS), and the mechanics below come from Razorcat Development GmbH’s own License Management Guide, a TESSY Application Note dated 19 March 2026 describing FLS version 9.0.5.

Stage 1: The Evaluation Licence

An evaluation is not a download. It is a licence key file issued against a specific machine.

Per Razorcat, the tooling arrives either with the TESSY full setup installer or as a standalone FLS setup. On Microsoft Windows, the first time TESSY starts the License Manager launches and displays the local host Id. You request the key through License, then Request..., then Online Request. On Linux the equivalent is flsutil request-license, which Razorcat states opens the corresponding URL “having the host Id already correctly filled in”.

Two details shape the plan. Razorcat states that “only company and university e-mail addresses are accepted”, so the request must come from your corporate domain. And Razorcat states you “should receive the evaluation license key file during the next working day”. Razorcat is based in Berlin, so in practice plan on a Berlin working day rather than an Indian one. Treat day one of a two-week evaluation as administrative.

Because the key is issued against a host Id, choose the evaluation machine before requesting it. A laptop due to be reimaged, or a build agent recreated nightly, wastes the request. Then test a real module from your own codebase with your own cross-compiler, never a sample project. Our ISO 26262 unit testing checklist sets out what a pilot has to demonstrate.

Stage 2: Where the Licence Lives

Two shorthand terms do most of the work across the tools industry. A node-locked licence is bound to one machine. A floating licence is held on a server and issued to whichever machine asks, up to the seats purchased. The distinction is about concurrency, not ownership.

Those are the industry’s labels rather than Razorcat’s own taxonomy. Razorcat’s License Management Guide does not use the node-locked term at all: it documents using a remote Floating License Server in chapter 2 and setting up a local licence server in chapter 3, and in both the key file is served by an FLS. What changes is where the FLS runs and where its key file is registered, so ask GSAS which licence forms Razorcat currently offers for your programme rather than assuming a node-locked SKU exists.

For a local server, Razorcat’s guide has you launch the Floating License Manager, select Server then Configure..., and give the absolute path to the key file, with Administrator privileges required if that server is to serve floating licences. For a remote server the client needs a host and a port: the Address and Port fields on Windows, the Host and Port variables in fls.conf on Linux, or RAZORCAT_FLS_HOST and RAZORCAT_FLS_PORT on either.

Two things catch teams out. The first is the network. Razorcat states that “the license mechanism needs one TCP port for the communication from the client application like TESSY to the Razorcat Floating License Server (FLS)”, and asks that security solutions be configured accordingly. That is a firewall request, and it should be raised before the seats arrive. The second is precedence: per Razorcat, “TESSY always prefers a locally running FLS”, so if clients are meant to reach the central server, any local FLS has to be stopped.

Stage 3: The Laptop That Leaves the Network

Floating licences assume the network is there. Plant visits, customer sites and secure labs assume it is not.

Razorcat’s answer is a checked-out, time-limited licence key file, a Windows-only feature. License then Info shows whether the server permits it, with a state line reading something like Checking out of license keys is enabled--up to 3 days. Per Razorcat, checkout is allowed for up to 3 days by default and the built-in maximum limit is 30 days. An administrator can set FLSD_90_KEY_DAYS to any number from 1 to 30, or set FLSD_90_FLAGS to --no-keys to disallow checkout entirely. Per Razorcat, both controls hold for remote hosts only: a time-limited key can still be checked out from the License Manager on the same machine that started the FLS.

The rule that bites is Razorcat’s own emphasis: “a time-limited license key file cannot be given back”. A seat checked out for a fortnight is gone for a fortnight, even if the engineer returns on day three. On a team running close to its seat count, one over-generous checkout before a plant visit in Pune or Chennai blocks a colleague in Bengaluru for the rest of the sprint.

Stage 4: Seat Planning, Concurrency Versus Headcount

The most common sizing error is buying one seat per engineer. Seats are consumed concurrently, and unit testing is bursty: heavy during test design and coverage closure, quiet during requirements work and reviews.

Razorcat’s guide contains a worked example, in the section explaining why the FLS supports access control lists. A department of ten employees spread around the globe orders six floating licences, “because they suppose that they do not need more than six licenses at the same time”; a second department of eight, all at one location, orders eight; a varying pool of external staff needs at most five. The figures are Razorcat’s illustration rather than a benchmark, but the reasoning transfers: co-located teams working the same hours need a ratio close to one, distributed teams do not.

Two instruments hold that arrangement in place. Access control lists restrict access by user name, optionally with host name, against a fixed contingent number per ACL. Per Razorcat, contingents are summed, a group is skipped if its contingent is larger than the amount of remaining product licences, and anything above the sum stays available without further restriction. Note one limitation: Razorcat documents that clients already connected when an ACL changes are not kicked out, though new connections are blocked.

Usage logging turns seat planning from an argument into a measurement. Per Razorcat, usage count logging outputs the number of currently checked out licences for each product and ACL group, while flsutil info displays available licences, usage counts, and the denied licence request count per user. Denied requests are the number that matters at renewal: they record somebody actually being turned away. Run that logging across a full project phase before buying more seats.

Stage 5: What Changes at Production Scale

Production scale is where automation joins the picture, and automation has an appetite engineers do not. A nightly regression run holding an ordinary seat is a seat nobody else can use, and if it still holds one at 09:00 it is a seat somebody is waiting for.

Razorcat separates the two cases with a Continuous Integration licence. Per Razorcat, this type “is meant for continuous integration using tessyd, e.g. by utilizing a Jenkins server”, and “the TESSY IDE cannot utilize this type of license”. It needs at least version 8.2.6 of the Razorcat floating licence server, and Razorcat lists the minimum supporting TESSY versions as 4.1.35, 4.2.21, 4.3.14, 5.0.4 and 5.1.7.

The behaviour is configurable, and the choice is policy rather than plumbing. Per Razorcat, tessyd can start with --enable-CI-license to take a CI licence and fall back to a normal one if none is available, or with --use-CI-license-only, in which case tessyd exits if none is free. The same choice is expressed through TESSYD_CI_LICENSE_FLAGS: 0 for a normal licence only, 1 to take a CI licence or fall back, 3 to take a CI licence or exit. Razorcat states the default is 1.

Teams that care about interactive availability prefer the strict setting. A build failing loudly because no CI licence was free is a problem you can see and fix; a build quietly borrowing an engineer’s seat surfaces instead as a colleague complaining on a Friday afternoon. We worked through the same question for a different vendor’s model in our note on Arm User-Based Licensing in CI/CD.

Licence Forms Compared

One more thing changes at production scale: the licence file stops being the only artefact under scrutiny. IEC 61508-3:2010 states that, in conjunction with IEC 61508-1 and IEC 61508-2, it provides requirements for support tools such as “testing and debugging tools”, which is why tool qualification evidence sits beside your test results. Razorcat states that TESSY is qualified for safety-related software development according to IEC 61508, IEC 62304, ISO 26262 and EN 50128, and supplies a Tool Qualification Package documenting the validation behind that statement. Razorcat’s public product pages currently document TESSY 5.1, so ask GSAS to confirm the Version 6 scope for your programme. Our IEC 61508 and ISO 26262 pages cover what assessors look for, and the AUTOSAR chain is walked through in our AUTOSAR verification chain guide.

Worth keeping straight while scoping: TESSY is a dynamic unit and integration test tool, so it executes your code. Static analysis tools reason about source without running it. They are licensed and deployed separately, and neither substitutes for the other.

Procurement Mechanics for Indian Teams

The technical plan then has to survive your purchasing system, and this is where international tool purchases stall. GSAS Micro Systems invoices in INR with a GST-compliant tax invoice, which keeps foreign-remittance and input-credit questions off the engineering timeline. Beyond the invoice, the question is which rail the purchase order travels on.

GSAS is registered on all four and is an MSME (Udyam) registered supplier, which is what makes the TReDS route available. Name the rail in the first conversation: supplier onboarding, or registration checks on GeM, can take longer than the technical evaluation itself, and it can run in parallel with the evaluation licence rather than after it. Teams in the UAE and Sri Lanka follow the same sequence with different tax and remittance paperwork.

Buying TESSY in India, the UAE and Sri Lanka

GSAS Micro Systems is the authorized Razorcat engineering partner for India, the UAE and Sri Lanka, and that covers more than the transaction. Our engineers scope the licence model against how your team actually works, help you place the evaluation key on the right machine, plan the FLS deployment and firewall path with your IT group, separate CI licensing from interactive seats before the pipeline is built, and support the tool qualification evidence your assessor will ask for.

Support is delivered locally from Bengaluru, Hyderabad, Chennai, Pune, Mumbai and Delhi NCR, with INR invoicing and procurement through GeM, SAP Ariba, Coupa and TReDS. For automotive programmes, see our automotive solutions page.

If you are moving from evaluation to production, or resizing a seat pool already under pressure, request a quote or a guided evaluation and we will scope the seat count, the CI licensing and the procurement route together.

Related reading

• How to Evaluate a Unit Testing Tool, running the evaluation the licence is for
• Unit Testing Fundamentals for Embedded C and C++, what the tool is for, if you are new to it
• Razorcat TESSY, the tool these techniques are run with in India, the UAE and Sri Lanka

Sources

• Razorcat Development GmbH, “License Management Guide”, TESSY Application Note, 19 March 2026, describing FLS version 9.0.5: chapters 2, 3, 4, 5.2, 8, 9 and 11
• Razorcat Development GmbH, FLS and TESSY download pages (FLS v9.0.5; “Download TESSY 5.1 for Windows and Linux”) and the TESSY qualification statement for IEC 61508, IEC 62304, ISO 26262 and EN 50128
• IEC 61508-3:2010, Edition 2.0 (published 30 April 2010), scope statement on requirements for support tools, given in conjunction with IEC 61508-1 and IEC 61508-2
• Reserve Bank of India (Trade Receivables Discounting System) Directions, 2026, dated 23 June 2026, definition of TReDS and Section J “Repeal and Saving”
• RBI Guidelines for the Trade Receivables Discounting System, 3 December 2014 as updated 2 July 2018: repealed 23 June 2026, historical context only