ja37

ADJUSTED REPRINT NEW E-MAIL ADRESS ADDED 2015, ORIGINAL PUBLICATION 1996
AUTHOR HAS CHANGED NAME TO ERIK ENGELBERT
The continuous development of
The JA37 Viggen fighter
Erik Norberg,
Chief Systems Engineer JA37
Swedish Defence Materiel Administration, FMV
Stockholm, Sweden
Abstract
The fast ongoing development in technology and tactics in the world put strong demands upon the different
systems in the armed forces. An ability to adapt the systems as well as training to new technological and tactical
threats is very important for continuous efficiency against a potential aggressor. This paper describes the
continued development of the JA37 Viggen fighter after its delivery during the 80´s. For some 15 years the
aircraft has been upgraded continually. A description of the aircraft and its upgrades as well as the development
process is made. The "Swedish profile" is to bring all resources together. With the goal to achieve high standards
in work and solve technological problems, this is successful. The overhead is also reduced. Some experiences or
lessons learned are lifted out from the so far successful project.
The Viggen Clan
The Viggen is not just a fighter, but a family of aircraft
dedicated to different tasks. The different versions are The
AJS37 (modified AJ37) Attack version, AJSF37
(modified SF37) Armed photo-reconnaissance, SK37
Trainer, AJSH37 (modified SH37) Armed sea
surveillance, JA37 Fighter, and The SK37E1
EW2
trainer.
The Aircraft JA37
The single seat JA37 Viggen has as all Viggens, the
famous double delta wing configuration and a single
engine. Based on its early 70's predecessor AJ37, the JA37
was introduced in The Swedish Airforce in 1980. It was
equipped with many revolutionary facilities such as:
electronic displays showing radar data and "moving map",
advanced Doppler radar containing digital signal
processing with look down -shoot down capability, and
the first digital flight control system in the world. The
pilot could review his mission by replaying recorded data
in a playback station. The latter was used mainly for
educational reasons. With a stronger engine (about +2000
lb.), adjustments in the airframe and improved hydraulics,
it was designed to be a better fighter than The AJ37.
Mainly, The JA37 is used as a fighter interceptor, but it
can also do fairly simple strike missions with rockets and
The Oerlikon 30 mm Gun.
1
The SK37E version is under development by SAAB. It is a double
seat EW trainer. SK37 and SK37E are technically the same, but the
Main armament is the semi-active RB71 "Sky Flash"
radar guided missile and The RB74 IR-missile (AIM9L).
JA37 has for many years been seen as one of the most
impressive fighters in non-communist Europe. The JA37
is - concerning its fundamental architecture - a good base
for continuous improvement. The central mission
computer (MC), with its serial data links to other
equipment, founded the base for ease of change. It is fairly
simple to add or change functionality compared to a
distributed system. Counting all the new facilities along
with the powerful MC, The JA37 became a "new aircraft
in an old shell". A phrase that will still be true with the
coming modification.
Development until now
The major changes in the system are:
 Fighter Link, 1985
 Ground Collision warning, 1986
 Flares, 1987
 Integration of The AIM9L Missile, 1987
 Ground controlled secondary information via data
link, 1987
 Multi target tracking, 1990
 Automatic Gun Aiming, 1992
 Chaffs, 1995
 MMI improvements, HOTAS and logic
 Fighter link improvements, more data
 RADAR improvements, automatic functions
Along with these large improvements, thousands of
smaller changes have been made during the years.
same aircraft can switch between these roles within hours. First
flight of the SK37E is expected later next year.
2 Electronic Warfare

Why improve the avionics (only)?
Many different aircraft in the world are currently
undergoing upgrades or modifications. Generally, only
the avionics are improved because is considered to be the
most cost-effective way to improve performance.
Compared to reduction of radar cross section or to
integrate a new engine to improve performance, it is fairly
easy to understand this.
Airforce 2000
Already with the aircraft 35 Draken the concept of
integrated defence systems using modern "system"
aircraft was selected as our strategy of the future. With the
Viggen the autonomous capability of the aircraft was
greatly improved and a data link for communication
within each tactical unit was developed. Also the
command and control systems were upgraded for
increased survivability, for example by the incorporation
of mobile units.
Although The JAS39 Gripen Aircraft has a high
autonomous capability, a new infrastructure around it to
support and reinforce its built in capabilities was created.
This system is being introduced in parallel to the Gripen
system, together creating the new "Airforce 2000"
(AF2000). In addition to the Gripen, the AF2000
comprise a new C3I system including mission planning
and post-mission evaluation systems. This system which,
is supported with real-time data from airborne missions,
enables shortening of the mission cycle time. This
together with a fast turn around time will increase the
sortie generation rate, which in turn will increase the
apparent size of force.
The JA37 Viggen was decided to fit into the AF2000 until
at least all JAS39 Gripen Fighters are operational.
General requirements on a system
For maximum system effectiveness3
normally three
major criteria are continuously balanced towards each
other - High Capability, Dependability and
Availability. Any reduction in either of them will affect
the entire systems performance. A high performance
system is worthless if it is not dependable.
3
Pse=Pc*Pd*Pa, the total probability of efficiency is the product of
the different probabilities, Probability of Dependability, Availability,
and Capability, e.g. design adequacy.
Added to these general requirements is the safety
requirement, covering both flight safety and weapon
safety.
The JA37 modification D (D-Mod)
The JA37 has until now mainly been fitted with new
software functionality. However, from here and further on
it was identified that it is no longer cost effective to
change the software without doing a major change in the
aircraft. The risk was that we would only change the
existing functionality, not add new. The C-version of the
JA37 does not fulfil the requirements to fit in to the
AF2000 concept.
Some weapons are somewhat old and new ones have to be
added. If the Viggen fighter should fit in the new AF2000,
it had at least to be equipped with the new tactical radio
system. It was decided that the Viggen also should be
modified to carry a new missile and a new jammer (U95).
This was followed by an analysis by FMV and the
industry to define necessary changes in the aircraft to
fulfil this task. The major changes are:
 New tactical radio for voice and data
 Integration of the AMRAAM missile
 New MC
 New stores management computer (SMC)
 Radar improvements (AMRAAM)
 New high resolution colour tactical display
 A new 1553B bus architecture
 Global Positioning System (GPS) - prepared
 Adding software buttons in the cockpit and a
modified throttle handle.
 Mission planning system integration including a data
transfer unit
 U95 Jammer pod
Addressing mainly the “Capability” requirement,
improvements in availability and dependability are also
made.

New avionics architecture
HUD TI
TD
TI237
Display Unit EP12
Mission Computer
CD207
SMS - ANP37
ANP 71
Air data unit
FCS - SA07
Aircraft system
Engine
UTB RUF
Data Transfer Unit
Cannon Veapon Stations
RADAR
INS & TILS
ECM
Radio
Voice & Data
GPS
AMRAAM
U95 Pod
AIM9L
RB71
IRST &
HMS/HMD
Recording/Loading
(BC)
Colour Codes
Optional
Plug in
New
Modified
Original
Serial link
1553B Bus
Transputer
10 Mbit/s link
*All connections
are not included
IFF & SSR
The new architecture of The JA37 is still based on the core
MC, which also is the Bus Controller for one of the 1553B
buses.
The 1553B buses are not connected to every single
computer, but to the computers/systems that are subject to
change, replacements, or further improvements. Between
the MC and the SMC a new 10 MBit/s serial link is
implemented. The SMC is the bus controller of the
weapon stations, whose interface to the weapons is based
on The MIL-STD 1760, but slightly changed mainly due
to safety reasons. This compliance to the standard also
improves the ability to integrate other modern weapons.
The new tactical digital radio system uses basically the
same principles as J-TIDS but is a different solution.
The tactical display (TI-237) is a brand new 120 DPI 6*8"
colour display. It can for example show transparent
colours in seven layers. The TI-237 is one of the keys to
make the new JA37 successful. It would be almost
impossible to manage the all-new functionality in the
cockpit without this display.
The data transfer unit is used for transferring data from the
mission planning system to the aircraft prior to a mission.
It is the same solution as for the AJS37 system. Also
added late in the project is the new flight data recorder.
Increased capacity as well as increased recording time
turned out to be unavoidable. The GPS installation is for
the time being put on hold. The Infra Red Search and
Track (IRST), Helmet Mounted Display (HMD) and the
Helmet Mounted Sight (HMS) are specified as options but
is not yet ordered by the Airforce. However, this
equipment is currently being flight tested in a JA37 test
aircraft to gain knowledge.
Software transition
Upgrading of the computer hardware still requires that
the existing functions is not changed or affected. To
develop the new software from scratch is very costly
and must be avoided. The solution in this case is based
on three different principles.

Cross compilers are used to reduce the time
consuming work to convert the old language to the
new. Manual work covers specific details of the code
and also adds quality assurance.
Code originally developed for the JAS 39 Gripen is
converted to “JA37 code” with some adaptations. The
latter is used for common functionality such as
communication and missile preparation. This code is
also undergoing manual work and quality reviews.
Since the same functionality is expected after the
transition, both the old and the new hardware is run
simultaneously in a subset of the system simulator to
identify if there are differences in the behaviour. This
makes the testing more efficient.
Flexibility
Being a fairly flexible fighter since the start, this is
improved even more with the modified JA37.
Mission Parameters System Settings
Software Change Hardware Change
Pilot
System
”Environment”
In flight
On ground
”Real Time”
Ease of change
Two major types of flexibility are identified:
 In air, or combat flexibility
 On ground, or maintenance flexibility
In the air the flexibility is based on the pilot's degree of
freedom to make tactical decisions and his ability to
command the aircraft systems to do certain things.
The system, which in itself is highly automated, allows the
pilot to override decisions to either help the system or
force the system to "do things his way". This is important
due to the difficulty to design a "perfect system" that does
everything right all the time. Normally the automatic
functions are used prior to manual override.
On the ground the system must be easy to upgrade with
new software, system settings, or other things. To change
memory circuit boards to accomplish a software change
belongs to ancient times.
On the ground the new flexibility advantages will be:
 Functions can be changed by simple parameter
settings instead of complex software development.
 To change the entire software by plugging in a single
"PC-Card" (not yet decided).
 The MC can upload new software in any other
computer at any time.
 Two complete software set-ups could be installed in
the aircraft to be changed between missions for
wartime trials and improvements.
 Improved capability to evaluate any recorded data in
the aircraft for improvements or change in tactics.
The mission-planning computer and the data transfer unit
- even if it is not directly related to a specific mission –
handles much of the flexibility which, in it self will also
ensure certain unpredictability to a potential aggressor.
The "Swedish development profile"
The initial operational capability of The JA37 was quite
soon followed up with improvements and added
functionality. Experiences from prioritised flight aircraft
and initial training identified desired new functions. Since
that time The JA37 have been improved every two or three
years; sometimes two changes have occurred within a
year.
To always be able to see the "horizon" of the next
milestone is a morale and motivation boost for the
development team members. The principle of updating
the system regularly is not unique to Sweden.

However, similar types of projects covering 10-15 years,
from time to time lack milestones that ensure personal
motivation.
The fairly short turn around between change request and
delivery is a benefit for the Airforce. They do not have to
live with an irritating annoyance or wait for new abilities
for several years.
Continuity
It is an ambition within the Swedish Airforce and FMV to
ensure that the same development team, counting in the
industry, should be engaged in the event of a crisis to
support or develop the system. This is impossible if the
system competence is not maintained continuously. To
have a flexible and changeable system along with an
experienced team during the entire life cycle is a success
factor during these circumstances.
Project structure and process
All projects must have a specification of what to achieve
before any work starts. In the JA37 project these
specifications are generally kept in a high level
description. Continuous discussions involving the
Swedish Airforce, FMV and the industry are the
fundamental base for deciding about “low level” details.
Formally, the industry is normally signed up with a
general agreement defining prices and level of profits and
is given orders on a two-year "level of effort" basis.
Regular meetings manage change requests and these are
poked directly into the project without time consuming
commercial negotiations. Concerning interfaces, power
consumption, environment, functionality limiting details,
etc., only the hardware is specified in detail prior to
procurement.
The development model or process in it self could be
criticised due to its lack of detailed customer
specifications early in the project. However, if the
fundamental requirements are well defined, the rest is
normally a matter of agreements, handling change request
and problem solving. It is similar to any project, but lacks
the heavy paper work prior to actually solving the
problem. This requires highly skilled persons and trust
between the different parties. This is hard to achieve if you
do not have the right culture in the project and a proper
contract. One year before delivery to the Airforce the
functionality of next release is "frozen".
4
The three first contractors in this list are counted as the "continuous
development team".
A typical aspect of the project is the lack of prestige and
the good contact between persons of different ranks. A
"low level" system engineer at the industry could easily
speak to an ordinary Airforce pilot or commander to
understand his problem or wishes. By understanding the
problem directly from "the horses mouth" (goes both
ways), the risk of unwanted, "filtered", or to "fat"
solutions with extra non-wanted functionality is reduced
to a minimum. The term "speak rank to rank" or "...I'm the
only person who has the authority to speak to the
customer..." does not go with the JA37-project. This
reduces the risk for commitments that in the end can not
be kept. A typical "functions" or integration meeting
generally has participants from several aspects of the
system. System engineers, Pilots, Maintenance experts,
Project Managers, Simulator experts, Integration experts,
Test pilots, etc., which ensure that a specific problem
could be heard and preferably understood by all involved
roles. A decision is fairly easy to make or recommend.
Normally, FMV is acting as "chairman" for these
meetings.
The "fixed price" type of contract for software
development has been tried for The JA37, but it became
difficult to handle the unpredictable flow of change
requests.
Contractors
The contractors4
that develop the D-Mod are:
 SAAB AB: Aircraft architecture, flight control
system software, MC software, stores managing
computer software, and system simulators. They are
also the main contractor, designer of the D- Mod,
modify the test aircraft and flight simulators.
 FFV Aerotech: Test and error monitoring software
and Display systems software (EP12). They also do
the integration tests of the D-Mod.
 Ericsson Microwave Systems: Radar
improvements.
 CelsiusTech Electronics: Data transfer Unit and
Radio system SRa80
 Ericsson SAAB Avionics: MC, SMC hardware, new
tactical display hardware and software, and U95
jammer software and hardware.
 Hughes: The AMRAAM missile
 Rockwell Collins: FR90 Digital Radio

Continuous Implementation (Hardware)
The implementation of the improvements is generally
managed through Technical Bulletins or Orders. Pure
software upgrades are generally just sent out to the
different wings, but hardware upgrades have to be
managed more carefully.
To be able to implement the upgrade while the aircraft is
grounded is recommended. However, a tactical upgrade
may not be allowed by the Airforce Head Quarters to wait
for the “right time” to be implemented. In that case the
Airforce build up dedicated modification teams with the
sole task to change the aircraft hardware. This also
strengthens the competence within the Airforce. If their
resources are not sufficient, FMV might have to order
assistance from the industry to be able to finish the
upgrade on time.
Due to the difficulty to match hardware deliveries in time,
a unique strategy for this modification has been developed
compared to earlier ones. The MC will detect the
hardware status of different systems and
activate/deactivate matching functionality. For example,
it will be possible to replace the old radio with the new
one without any software change in the aircraft. This is
allowed only for non-safety-critical functionality.
The D-Mod is the one of the largest aircraft modification
in the history of the Swedish Airforce.
Schedule
The aircraft has entered the modification line and every
one will be finished before the millennium 2000. Along
the way, new hardware will be "plugged" into the system
as the tests are finished. Currently, three JA37 have been
modified for flight tests.
A word about contracts
A contract must reflect the principles with which the
project are managed. A fixed firm price contract could in
the worst case be combined with a poor specification.
This limits the degrees of freedom not counting the time
loss, commercial, and juridical work. As described earlier,
the development project is driven with the general goal to
minimise loss of time and unnecessary negotiations and
paperwork.
With the right agreements, a change request could by
definition be approved and flight-tested within a couple of
weeks instead of several months. A level of effort contract
combined with a deeply engaged customer is very good
for productivity.
A single upgrade – a generic example
Every upgrade follows a similar pattern from idea to
release:
 A specification or a change requests list is the base
for a software upgrade
 The detailed functionality is defined in a series of
meetings
 Development of the new functions
 Separate testing in the different systems
 Integrated functions test in a hardware rig integrated
with a flight system simulator (SAAB)
 HW-changes are verified in a rig with exactly the
same electrical configuration as the aircraft it self
(FFV)
 Flight safety assessment prior to flight test (SAAB)
 Flight test (FMV)
 Education of pilots in upgraded Airforce simulators
(normally up to 6 months prior to the sharp release)
 Tactical, technical, and operational evaluation by the
Airforce (not only test pilots)
 The technical bulletin along with the software or
hardware is released
Some steps are iterated a different number of times
dependent of the test results, and some of the activities are
made alongside.

Discussion (FAQ)
Q: Is it really effective with all these meetings to define
functionality along the way?
A: Yes, you probably have to have a lot of meetings
anyway prior to releasing a spec. Then you still do not
know what difficulties are ahead of you. The continuous
development of requirements is balanced with experience
from tests. The risk of producing wrong specifications is
then reduced to a minimum, and you more or less always
get what you pay for.
Q: "The Swedish profile" sounds pretty much like the
"buzz"-words "IPT-Integrated Product Teams" or "JIT-
Joint Integration Teams"?
A: Yes, but in Sweden, being a small country, this
principle - whatever it is named - is often a necessity
because we do not have the resources to create
competition all the time. It also creates the possibility to
achieve much with small resources. These are the reasons
why we have been doing it for decades.
Q: This close co-operation within the technology: does it
also concern commercial issues such as joint surveys?
A: It depends entirely on how the contracts are
constructed, but generally - yes.
Q: Are you on track with your original schedule?
A: We currently have an "acceptable slip". There are
always unpredictable factors in a project. In Sweden for
example, you sometimes have to wait for weeks before the
weather allows you to do live fire with missiles.
Integrating new technology in an old aircraft also causes
“surprises” from time to time. The slip could be estimated
to about 5-10%.
Q: It is not more effective “in the long run” to adapt every
computer to 1553B rather than keeping all these serial
links?
A: It is not as important how computers communicate
compared to where you actually put different functions.
The serial links also ensures a certain redundancy.
Conclusion - Experiences
Technically, the experience from using a core computer
(MC) for aggregated system functionality has been
successful for The JA37. It is hard to foresee how this
“ease of change” is maintained in the future. The systems
are becoming even more complex in the near future, and
the problem not only gets technically harder to solve, but
it is also a matter of getting the right competence to do the
right thing in the system. The programmers of the Mission
Computer may lack some knowledge about a specific sub-
system, and the designer of a sub-system may lack
knowledge about the main system. It looks as it is
inevitable to merge in more detailed specifications earlier
in the process at the cost of ease of change. Well-written
interface specifications and the rules surrounding “object
orientation” are becoming even stronger. With this in
mind I still believe that many projects in the future could
gain from the experiences described here and still not
compromise the quality of the work done.
Useful experiences could be described as:
 Be an active project management who does not wait
for things to happen.
 Solve the problems together instead of arguing in
court.
 The customer and user must engage themselves in the
project to minimise the risk of "autonomous
engineering".
 Allow good ideas to be tried out, even if they are not
accepted in the end.
 Be informal if possible - talk!
 Always improve the development process. Get the
right tools to reduce cycle times.
 Correlation between contract and type of project is
very important. A fixed firm price could be bad for
both the contractor and the customer. Create a "win-
win" situation.
 Engage all kinds of users, not only formally
appointed persons.
 The "Swedish profile" works very well in Sweden.
Cultural gridlock with "water tight doors" could be a
disaster for this type of project.
Acknowledgements
Thanks to all my colleagues at FMV, SAAB AB, and the
Swedish Airforce who helped me with valuable
viewpoints.
References
H Lindell, "Development and integration of The JAS39
Gripen Avionics system", FMV 1996.

Author Biography
Erik Norbergi
is educated in Electronics, computer
technology, telecommunications, and aircraft systems. In
1987 he worked with radars in the Swedish Air Defence.
He graduated from The Royal Institute of Technology
(KTH) in 1990 (Flight Operations). Since then he has
mainly been dedicated to the Aircraft 37 project working
i E-mail: erik.engelbert@gmail.com
as a project manager of RADAR upgrades. He has aslo
been responsible for radar research programs aiming
towards future airborne systems. Erik became Chief
Systems Engineer for Viggen in late fall 1996. Currently
he is also engaged in process development at FMV
concerning Systems Engineering. This is his first
international paper.
REPRINT CONTACT
ERIK ENGELBERT
429 32 KULLAVIK
070-3027771

ja37

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (16)

Similar to ja37

Similar to ja37 (20)

ja37