Category: Uncategorized

Light Combat Aircraft – “TEJAS”

Background:The Light Combat Aircraft Program was started with Two Goals, a, Indigenous Production of a combat aircraft for the Air force with its requirement as a base rather than stretching or curtailing operational parameters. b, To replace the aging MiG-21 Fighters/Fighter-Bombers, nearing (or some say) end of operational life.Conception & Development :Due to the force’s familiarity with old-soviet era hardware and the mission parameters , the basic design overlay and requirement was floated by the then Air force operations directorate. The DRDO, HAL and various agencies were involved in the initial design of the same by 1983 (that was when I was 3 yrs old L) . In 1985 the overall coordination of the project was given to the Aeronautical Development Agency., With HAL taking the back seat as prime contractor. HAL brought about the integration of the various works being done under various Govt. labs and Universities (including IITs of course) . But like most of the programs before (I really am ashamed to state it here) some technology wasn’t in place or cannot be sourced. But that didn’t stop the development though significantly delayed, It was decided to design 2-4 Technology demonstrators to see if we could design this. And viola.! By 1995 march the 1st of the TD-1 was rolled out . And soon certain problems emerged like the composites (which up to that stage were never fabricated in India or worst didn’t had facilities for their fabrication in a mass level) and some 3 years we also got the Sanctions from Clinton administration due to the “Laughing Buddha” events., and the GE404 engines were in the list of restricted technologies and we hadn’t had a clue how to test the Indigenous “Kaveri” engine for Hi-Altitude Flight simulation and had to get help from the Russian(S) friends, though they were more interested in selling the Klimov 513E engines rather than test our engines . And finally we somehow tested and being making some improvements (what its, I really don’t understand , may be they are doing the engines MS style. Releasing or completing before the proj is over and sending SP and bug fixes for five years). And in 2003 we also named in “Tejas” by our former PM . Vajpayee. Now we are really in a breakthrough (the reason I thought of posting it in the 1st place) The Engine is in place and the technology (I really admire the electronics part (not bcoz I am an electronics engr) but because its really amazing)

Features:
If I told you , that it’s the world’s most technologically advanced fighter in its class , would you believe me? . but the answer is surprisingly yes.
The digital FBW system of the LCA is built around a quadrauplex redundant architecture to give it a fail-op-fail-op-fail safe capability. It employs a powerful digital flight control computer (DFCC) comprising four (independent ) computing channels, each powered by an independent power supply and all housed in a single line replaceable unit (LRU). The system is designed to meet a probability of loss of control of better than 1×10-7 per flight hour. The DFCC channels are built around 32-bit microprocessors (though talks suggest this may be upgraded to the 64bit elrbus based core manufactured locally in BEL in operational versions) and use a safe subset of Ada language for the implementation of software. The DFCC receives signals from quad rate, acceleration sensors, pilot control stick, rudder pedal, triplex air data system, dual air flow angle sensors, RWR , Satellite Navigation Beacons, C4P and many others mission and op-sensors. The DFCC channels excite and control the elevon, rudder and leading edge slat hydraulic actuators. The computer interfaces with pilot display elements like multifunction displays through MIL-STD-1553B avionics bus and RS 422 serial link. Multi-mode radar (MMR) is the primary mission sensor of the LCA in its air defence role, will be a key determinant of the operational effectiveness of the fighter. This is an X-band, pulse Doppler radar with air-to-air, air-to-ground and air-to-sea modes. Its track-while-scan capability caters to radar functions under multiple target environment

And when I tell its amazing , I mean the following ,

This quadrauplex redundancy is yet to be perfected by Boeing and (believe) Boeing is talking with HAL for the Tech-transfer for that.
This elevon , rudder and leading control surface is really one of its kind tech and Not even Lockheed-Martin F-22 has been able to adapt it .(its said the F-35 and Eurofighter along with S-37(not su-37)employs them )
The Antenna is really very-light in weight , supposedly <5Kg and can simultaneously track upto 25 targets and can lock on to 2 diff target at once (ie. An Arial target and a ground or sea based target whose coordinates can be passed to other fighter-bombers or sea/land assets or may be it can engage with its ordinance itself) . this capability is new in our country outside of Vetrivel (Su-30MKI) Actually I can write on and on but its really great with one short coming though the engines and their development. And I personally feel that we can go on for some engine intermediately while kaveri is being developed . May be Klimov or Snemeca (I don’t favour Ge404 or B.Ae because they are highly underpowered than the airforce’s requirement) Other technical specs are given below.

HISTORY:
First Flight : January 2001

Service Entry :planned for 2005 to 2010

CREW: 1 (Pilot)

ESTIMATED COST: $21 million (FY:2000)

AIRFOIL SECTIONS:
Wing Root : composites and Duralmium Alloy
Wing Tip : FRB and Titanium aluminium alloy

DIMENSIONS:
Length 43.27 ft (13.20 m)
Wingspan 26.88 ft (8.20 m)
Height 14.42 ft (4.40 m)
Wing Area 412.6 ft2 (38.4 m2)
Canard Area :not applicable

WEIGHTS:
Empty 12,125 lb (5,500 kg)
Typical Load 18,740 lb (8,500 kg)
[clean] Max Takeoff 27,560 lb (12,500 kg)
Fuel Capacity internal: 795 gal (3,000 L)
external: 1,055 gal (4,000 L)
Max Payload 8,820 lb (4,000 kg)

PROPULSION:

Powerplant (prototype) one General Electric F404-F2J3 turbofan
(production) one GTRE GTX-35VS Kaveri turbofan

Thrust (F404) 18,100 lb (80.50 kN)(GTX) 20,200 lb (89.86 kN)

PERFORMANCE:
Max Level Speed at altitude: 1,195 mph (1,920 km/h)
at 36,000 ft (11,000 m), Mach 1.8 at sea level: unknown
Initial Climb Rate unknown
Service Ceiling 50,000 ft (15,250 m)
Range 460 nm (850 km) g-Limits +9 / -3.5

ARMAMENT: Gun one 23-mm GSh-23 twin-barrel cannon (220 rds) Stations seven external hardpoints Air-to-Air Missile medium- and short-range AAM Air-to-Surface Missile up to two conventional cruise missiles, anti-ship missiles Bomb laser-guided bombs, conventional bombs Other rocket pods

KNOWN VARIANTS: LCA-TD-1 First technology demonstrator equipped with a General Electric F404 turbofan LCA-TD-2 Second technology demonstrator LCA-PV-1 thru PV-4 Single-seat prototype vehicles that should be at or very close to production form, equipped with in-flight refueling capability LCA-PV-5 Two-seat trainer prototype vehicle LCA Production model for the Indian Air Force Trainer Two-seat trainer model Navy model A navalized version with strengthened landing gear and a redesigned forward fus
elage has been proposed for use aboard a future Indian aircraft carrier MCA Planned Medium Combat Aircraft derived from the LCA, supposed to possess greater stealth characteristics and thrust-vectoring capability

KNOWN COMBAT RECORD: not yet in combat service
KNOWN OPERATORS: India ·

Sources and Methods
Specs from FAS and many petty discussion groups and some official groups like DRDO and ADA. Picture courtesy of ADA and may be subject to copyright .

Special Thanks : I really longed long to write this long time before but since Chandra asked me to post some details If I can .

For Further information See:
www.drdo.com/products/lca.htm
www.fas.org/man/dod-101/sys/ac/row/lca.htm
www.defencejournal.com/jun99/lca.htm
www.bharat-rakshak.com/IAF/Info/LCA-Section.html
http://www.ada.gov.in/

Knowledge needs to be free!
MySQL on AWS: RDS vs EC2

MySQL on AWS: RDS vs EC2

We have recently gone through a very familiar dilemma, moving the MySQL database server of a nascent solution from a hybrid On-Premise and Azure environment to the AWS Infrastructure. Whether to go with a couple of EC2 instances and have a master-slave configuration or to go with AWS’ packaged offering for the RDBMS, viz., RDS. 
This is, in fact not a new question at all.  It would have come to any person who was getting plugged into AWS/Cloud infrastructure. Personally, for me, it was like 5th or 6th Datacenter setup in AWS. Still, the reason I had this question is, in part due to the fact that the solution I was trying to port was very nascent and was not having super high write-rate requirements.
So, in the absence of high-throughput requirements, did it really made sense to go to a full-blown RDS setup? Or is it worth the time to install, configure a 2 node cluster and write some automation scripts for backup, recovery, etc?
Question: What does RDS really offer that you cannot get with a self-configured MYSQL on RDS
Answer: It really boils down to the situation and the preference you have for control, flexibility and performance/high-availability.
 
 
 

Building a Log-Management & Analytics Solution for Your StartUp

Building a Log-Management & Analytics Solution for Your StartUp

Background:

As described in an earlier post, I am working with an early stage startup. So, one of my responsibility is to architect, build and manage the cloud infrastructure for the company. Even though I have had designed/built and maintained the cloud infrastructure in my previous roles, this one was really challenging and interesting. Due in part to the fact, that the organisation is a high growth #traveltech startup and hence,

  1. The architecture landscape is still evolving,
  2. Performance criteria for the previous month look like the minimum acceptable criteria the next (in terms of itineraries automated, rating, mappings, etc.)
  3. The sheer volume of user-growth
  4. Addition of partner inventories which increases the capacity by an order of magnitude

And several others.  Somewhere down the lane, after the infrastructure, code-pipeline and CI is set-up, you reach a point where managing (read: trigger intervention,  analysis, storage, archival, retention) logs across several set of infrastructure clusters like development/testing, staging and production becomes a bit of an overkill.

Enter Log Management & Analytics

Having worked up from a simple tail/multitail to Graylog-aggregation of 18 server logs, including App-servers, Database servers, API-endpoints and everything in between. But, as my honoured colleague (former) Mr.Naveen Venkat  (CPO of Zarget) used to mention in my days with Zarget, There are no “Go-To” persons in a start-up. You “Go-Figure” yourself!
There is definitely no “One size fits all” solution and especially, in a Start-up environment, you are always running behind Features, Timelines or Customers (scope, timeline, or cost in conventional PMI model).
So, After some due research to account for the recent advances in Logstash and Beats. I narrowed down on the possible contenders that can power our little log management system. They are,

  1. ELK Stack
  2. Graylog
  3. Logstash 

(I did not consider anything exotic or involves us paying (in future) anything more than what we pay for it in first year. So, some great tools like splunk, nagios, logpacker, logrythm were not considered)

Evaluation Process:

I started experimenting with Graylog, due to familiarity with the tool. Configured it the best way, I felt it appropriate at that point in time. However, the collector I had used  (Sidecar ) had a major problem in sending files over 255KB and the interval was less than 5 secs.
One of the main use-case for us is to ingest the actual JSON data from multiple sources. (We run a polynomial regression  across multiple sources, and use the n th derivatives to do further business operations). When the daily logs you need to export is in upwards of  500MB for an app (JSON logs), add other application log(s), web-server, load-balancers, CI (Jenkins), database, redis and … yes,  you get the point?
(())Upon further investigation, The sidecar collector was actually not the culprit. Our architecture had accounted for several things, but by design, we used to hit momentary peaks in CPU utilisation for the “Merges”.  
So, once the CPU hit 100% mark, sidecar started behaving very differently. But, ultimately fixed it with a patched version of sidecar.
 
 

Bitnami